Re: which OutputStreams are buffered?
On Sat, 17 May 2008, Neil Coffey wrote:
Tom Anderson wrote:
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.
As far as your Java application is concerned, I think you should
generally treat "secret buffering at the OS level" as "no buffering" and
should wrap in a BufferedInput/OutputStream-- otherwise you have the
overhead of the native call on every single read/write.
Yes, that's exactly what i said in my post:
"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."
Except that you *do* need to be aware of the secret buffering for
correctness reasons:
"you can't rely on data being written to a file until you've flushed the
FileOutputStream."
So, for things like FileOutputStream, you have to treat them as both
unbuffered (by wrapping them in a buffered stream) and buffered (by
remembering to flush) at the same time!
I believe you don't need extra buffering in the streams given to you by
some Servlet implementations (they do their own Java-side buffering to
handle the HTTP protocol), though I'd be interested if anyone has
further insight on this.
Good point.
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.
For similar reasons to above, it's generally best to add a Java buffer
unless you have strong grounds for not doing so. These compression
stream classes may "naturally" work on a buffer, but if the buffer is
held natively, then it's a native call to fetch each individual byte
unless you buffer in Java.
True.
If memory serves correctly, it was the flavour of InputStream you get
from ZipFile.getInputStream() whose single-byte read() method creates a
new one-element byte array on each call and then calls the multi-byte
version...
Urgh!
tom
--
1 p4WN 3v3Ry+h1n G!!!