buffer : Java Glossary

If you wrote a byte at a time, since the hardware works in 512-byte sectors at a time, the OS would need to read the sector, plop your byte into it and write the entire sector back. This would take at least 2 disk rotations, perhaps 3. Even if you wrote your data 512 bytes at a time, when you went to write the next sector, its spot would have just past the head, so you would have to wait an entire rotation for its spot to come round. If you wrote 131,072 bytes (still less than 1 physical track) at a pop, you could do that all in one rotation.

Ideally, if you have enough RAM, you do the I/O in one whacking huge file-sized unbuffered chunk. Java has a number of classes that let you process a file buffered in convenient small logical chunks, often line by line. The buffered classes transparently handle the physical I/O in bigger chunks, typically 4096 bytes. The classes store each large chunk for physical I/O in a separate piece of RAM called a buffer. Unless the buffer size for the physical I/O is at least twice as big as the size of the logical chunks you process, there is not much point in buffering. The extra buffering copying overhead will just slow you down.

The File I/O Amanuensis will teach you how to do I/O either buffered or unbuffered. You can try it both ways, and see which works faster. You can also experiment with buffer sizes. The bigger the buffer, the fewer the physical I/Os you need to process the file. However, the bigger the buffer, the more virtual RAM you will use, which may trigger more swapping I/O. Further, there is not much point in having a whacking big buffer for a tiny file. It will take only a few I/Os to process the file anyway.

You will find that buffer sizes that are a power of two tend to work faster than other sizes. This is because disk and RAM hardware are designed around some magic sizes, typically 256, 512, 1024, 2048, 4096, 8192, 16,384, 32,768, 65,536, 131,072 and 262,144 bytes. Buffers that are powers of two naturally do I/O in physical chunks that align on powers of two boundaries in the file. This too makes the I/O more efficient because the hardware works typically in 512 byte sector chunks. If you do unbuffered I/O, likewise try to start your I/Os on boundaries that are even multiples of some power of two, the higher the power of two the better. e.g. it is better to start I/O on boundaries that are even multiples of 8096 rather than just 128. Sometimes it pays to pad your fixed-length records up to the next power of two. If you can help it, arrange your logical record size and buffer size so that logical records are aligned so that they never (or rarely) span two buffer fulls. It also helps to have your buffers aligned on physical RAM addresses that are even powers of two as well, though you have no control of that in Java.

In the olden days, CØBØL programs used double buffering. They used two or more buffers per file. The computer would read ahead filling buffers while the program was busy processing one of the previous buffers. Oddly, Java does not support this efficient serial processing technique, though sometimes the operating system maintains its own private set of read-ahead buffers behind the scenes. Unfortunately, the OS’s cascaded buffering is less efficient than using a single layer. You have the overhead of copying plus the wasted RAM for the buffers that are not actually used for physical I/O. Java never has more than one buffer per file and hence cannot simultaneously process and do physical I/O, unless of course it uses Threads. Even with Threads, you can’t pull off double buffering with any ease.

The term double buffering also refers to a technique of constructing Images off screen then blasting them onscreen once they are complete, as a way of creating smoother animation.

If you wrote 128K a byte at a time using a 64K buffer there would be only two physical 64K I/Os. This would be slightly slower that using unbuffered I/O to write the entire 128K in one I/O because of the extra physical I/O, the RAM overhead for the buffer and the CPU overhead of copying the data to the buffer.

When To Buffer

• To process a file whole file a time, read the entire file in one giant unbuffered I/O.
• If a file is too large to process all in RAM, read it buffered, and process it a chunk, line, field or char at a time.
• To copy files or download streams use the FileTransfer class which reads unbuffered a large chunk at a time.
• If you need the readLine method, you must use buffering.