Re: which OutputStreams are buffered?
On Fri, 16 May 2008, Rex Mottram wrote:
There is a java.io.BufferedOutputStream whose purpose is well
documented, basically as a good thing to wrap around an unbuffered
OutputStream (at least if you want buffering). However, and surprisingly
to me, a number of the other OutputStreams in java.io do not document
whether they are buffered, and thus it's not clear to me whether I
should wrap them or not.
I believe that BufferedOutputStream is the only one that does buffering
*in java* (more or less ...), but others may involve buffers out in native
code or the OS. FileOutputStream, for instance - i believe every write
turns into a call to the OS or C library's write routine, but that may not
immediately put bytes onto a platter. The stream you get from a Socket is
another - all writes go to the TCP implementation, but that won't
necessarily send them immediately.
The point of buffering on the java side is that it saves you native calls
- you make one call when you have a kilobyte of data to send, rather than
one every time you have a morsel of data to write. This can be a big
performance win. Basically, always wrap.
You still have to worry about the native buffering for correctness, though
- you can't rely on data being written to a file until you've flushed the
FileOutputStream.
Now, that "more or less" above is about the various streams which do
transformations on data passing through them, and which have to do some
buffering to do that. That means GZIPOutputStream, DeflaterOutputStream,
CipherOutputStream, and possibly others. These require special attention
to wring all their bytes out of them. However, i think this is pretty well
documented in each case.
tom
--
It's the 21st century, man - we rue _minutes_. -- Benjamin Rosenbaum