# Java Sequential IO Performance

DevFeed: [Java Sequential IO Performance](<https://devfeed.tech/articles/java-sequential-io-performance-13622.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/12/java-sequential-io-performance.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-12-26T19:47:00Z

Content type: article

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [IO](<https://devfeed.tech/topics/io.md>), [Filesystems](<https://devfeed.tech/topics/filesystems.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Logging](<https://devfeed.tech/topics/logging.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [files](<https://devfeed.tech/tags/files.md>), [io](<https://devfeed.tech/tags/io.md>), [java](<https://devfeed.tech/tags/java.md>), [latency](<https://devfeed.tech/tags/latency.md>), [nio](<https://devfeed.tech/tags/nio.md>), [performance](<https://devfeed.tech/tags/performance.md>)

## 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