Java Glossary : buffer

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : B words : buffer.

buffer

Because of hard disk latency, when you do I/O, it will go faster if you do it in a few big physical I/O chunks rather than a number of small ones. Ideally, if you have enough RAM, you do the I/O in one whacking huge file-sized chunk. Java has a number of classes that let you process a file 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 and 65,536 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. 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 phyisical 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. Java does not use this technique, though sometimes the operating system maintains its own private set of read-ahead buffers behind the scenes. Unfortunately this form of 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 Image s off screen then blasting them onscreen once they are complete, as a way of creating smoother animation.

File ¤ Image ¤ record

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 1920.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/buffer.html	J:\mindprod\jgloss\buffer.html