# NIO Published articles for NIO. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Forcing bytes downward in Okio DevFeed: [Forcing bytes downward in Okio]() Original publisher: [Read original article]() Published: 2016-09-06T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Library](), [Streams](), [IO](), [Java](), [Code]() Tags: [code](), [io](), [java](), [jdk](), [library](), [nio](), [performance](), [streams]() ### AI overview This article explains how Okio moves buffered bytes through its sink chain. It compares flush(), emitCompleteSegments(), and close-related behavior, emphasizing their differences, buffering costs, and effects on correctness and throughput. ### Source excerpt Okio's BufferedSink is a high-level abstraction for writing binary and character data as bytes. Its design stems from frustrations with the JDK's java.io.* and java.nio.* libraries. At Droidcon Montreal last year I gave a presentation comparing it with the former, but also showcased Okio's concept of a segment and how it enables the library to cheaply move bytes. If you aren't familiar with Okio I encourage you to go watch the presentation first since the rest of this post will assume at least cursory knowledge of its types. If you never look at the source code of Okio you won't know that this segment concept exists. It's an implementation detail for performance that remains completely opaque to the consumer of the library. That is, except for one* notable exception: the emitCompleteSegments() method on BufferedSink. This method is part of a family of three methods which force buffered bytes to be moved to the underlying Sink. Their difference is subtle, but understanding that difference ensures correctness and can make or break throughput. First let's understand the difference in behavior and then look at some use cases for each. flush() Flush is a common concept in stream APIs and its semantics remain unchanged in Okio. Calls to this method cause all buffered bytes to be moved to the underlying Sink and then that Sink is also instructed to flush itself. When calls to flush() return, you are guaranteed that all bytes have been sent all the way to the destination Sink. When multiple levels of buffering are in use, a call to flush() will clear the buffers at every level. In Okio multiple levels of buffering are so cheap that it's practically free. A flush just amounts to each level moving its segments down to the next level of the chain. With java.io.* streams, however, multiple levels of buffering require each level to allocate and manage its own byte[]. This means that a flush operation will result in each level doing an arraycopy() of its data down to the next lev ## Native C/C++ Like Performance For Java Object Serialisation DevFeed: [Native C/C++ Like Performance For Java Object Serialisation]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2012-07-05T17:51:00Z Content type: tutorial Language: en Sources: [Mechanical Sympathy]() Topics: [Java](), [IO](), [systems](), [Processes]() Tags: [code](), [distributed](), [io](), [java](), [low-latency](), [native](), [nio](), [object](), [performance](), [processes](), [serialization](), [systems]() ### AI overview This article compares Java Serialization, a ByteBuffer-based binary protocol, and Unsafe-based serialization for converting Java objects to byte streams. It reports that Unsafe can reduce serialization time for a small object from about 10,000 nanoseconds to less than 100 nanoseconds, while binary approaches use fewer bytes than Java Serialization in the example. ### Source excerpt Do you ever wish you could turn a Java object into a stream of bytes as fast as it can be done in a native language like C++? If you use standard Java Serialization you could be disappointed with the performance. Java Serialization was designed for a very different purpose than serialising objects as quickly and compactly as possible. Why do we need fast and compact serialisation? Many of our systems are distributed and we need to communicate by passing state between processes efficiently. This state lives inside our objects. I've profiled many systems and often a large part of the cost is the serialisation of this state to-and-from byte buffers. I've seen a significant range of protocols and mechanisms used to achieve this. At one end of the spectrum are the easy to use but inefficient protocols likes Java Serialisation, XML and JSON. At the other end of this spectrum are the binary protocols that can be very fast and efficient but they require a deeper understanding and skill. In this article I will illustrate the performance gains that are possible when using simple binary protocols and introduce a little known technique available in Java to achieve similar performance to what is possible with native languages like C or C++. The three approaches to be compared are: Java Serialization: The standard method in Java of having an object implement Serializable. Binary via ByteBuffer: A simple protocol using the ByteBuffer API to write the fields of an object in binary format. This is our baseline for what is considered a good binary encoding approach. Binary via Unsafe: Introduction to Unsafe and its collection of methods that allow direct memory manipulation. Here I will show how to get similar performance to C/C++. The Code import sun.misc.Unsafe; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; import java.lang.reflect.Field; import java.nio.By ## Java Sequential IO Performance DevFeed: [Java Sequential IO Performance]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2011-12-26T19:47:00Z Content type: article Language: en Sources: [Mechanical Sympathy]() Topics: [Java](), [IO](), [Filesystems](), [Cache](), [Latency](), [Logging]() Tags: [cache](), [data](), [database](), [files](), [io](), [java](), [latency](), [nio](), [performance]() ### AI overview This article examines the performance characteristics of Java mechanisms for sequentially writing to and reading from files. It focuses on pre-allocated files, explaining how contiguous blocks and filesystem metadata affect access, and describes tests using 400 MB and 8 GB files under different cache conditions. ### Source excerpt Many applications record a series of events to file-based storage for later use. This can be anything from logging and auditing, through to keeping a transaction redo log in an event sourced design or its close relative CQRS. Java has a number of means by which a file can be sequentially written to, or read back again. This article explores some of these mechanisms to understand their performance characteristics. For the scope of this article I will be using pre-allocated files because I want to focus on performance. Constantly extending a file imposes a significant performance overhead and adds jitter to an application resulting in highly variable latency. "Why is a pre-allocated file better performance?", I hear you ask. Well, on disk a file is made up from a series of blocks/pages containing the data. Firstly, it is important that these blocks are contiguous to provide fast sequential access. Secondly, meta-data must be allocated to describe this file on disk and saved within the file-system. A typical large file will have a number of "indirect" blocks allocated to describe the chain of data-blocks containing the file contents that make up part of this meta-data. I'll leave it as an exercise for the reader, or maybe a later article, to explore the performance impact of not preallocating the data files. If you have used a database you may have noticed that it preallocates the files it will require. The Test I want to experiment with 2 file sizes. One that is sufficiently large to test sequential access, but can easily fit in the file-system cache, and another that is much larger so that the cache subsystem is forced to retire pages so that new ones can be loaded. For these two cases I'll use 400MB and 8GB respectively. I'll also loop over the files a number of times to show the pre and post warm-up characteristics. I'll test 4 means of writing and reading back files sequentially: RandomAccessFile using a vanilla byte[] of page size. Buffered FileInputStream and Fi