Roedy Green wrote:
> I put in primitive sort of progress meter into a little Java program
> that read a large CSV file [System.out.print(".")] I was quite
> surprised to discover I could easily see the pause when it read the
> next buffer full -- synched with the disk light. (Maybe I err. Maybe I
> was seeing GCs).
>
> Way way back in the olden days when computers had about 16K and you
> coded in assembler, we did double buffering. In other words, when you
> were reading a sequential file, you processed one buffer while the i/o
> hardware was filling the other. This was the NORMAL way of doing
> things. Later, double buffering was built in to COBOL. You got it by
> default without writing any code.
>
> Today, when we have RAM coming out our ears we have reverted back to
> SINGLE buffering. We alternate between processing and waiting for I/O
> on the same buffer.
>
> What is the matter with us? It is as though we imagine we still have a
> single threaded DOS OS.
>
Double Buffering generally refers to rendering, not look-ahead caching,
which is what you seem to be describing.
As for caching/buffering that you suggest, it is usually handled at the
OS level, rather than at the app level. You can add additional
buffering by using BufferedInputStream. Also, depending on your
application, if you really need that big of a speed increase, decide to
read the whole thing into memory up front.
Alternately, if you want to read ahead, you can create your own
multi-threaded system to do so.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
|
