Name: nt126004 Date: 11/15/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)


When GZIPOutputStream writes its (10?) header bytes (and, I think, its trailer
checksum), it writes the bytes one at a time. This is inefficient, especially
when writing directly to an unbuffered (eg TCP network) stream. It implies
wasted I/O traffic to disc or network without careful workaround.

Also, flush() should probably not be passed on downstream until a completed
output block is ready, else even a (new GZIPOutputStream(new
BufferedOutputStream(myNetworkStream))) forces out the header block of 10 bytes
before there is anything else ready, and that initial 10 bytes is a wasted
packet/etc somewhat undermining the value of compressing the output stream at
all!

Obviously, all this can be worked around, but a simple tuneup of the JDK code
would make all sorts of applications (such as the example compression filter in
  Tomcat 4.0.1 / Catalina with small output streams and chunked output) work
noticably better.

In passing, you might consider allowing a user to construct the
GZIPOutputStream with a compression level (the equivalent of the command-line
flags -1 to -9 and -f or -b) to squeeze more value out of the compression when
bandwidth is really tight and CPU is plentiful.



  Synopsis : at least write the header and trailer into a local byte[] buffer
first before pushing them downstream in one go, and possibly suppress passing
on flush() until a whole output block is ready. Allow the user to maximise
compression.
(Review ID: 135448)
======================================================================