JDK-6399199 : Improve performance of Deflater
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2006-03-16
  • Updated: 2014-01-16
Related Reports
Relates :  
JDK-6206933 - GZipOutputStream/InputStream goes critical(calls JNI_Get*Critical) and causes slowness
Relates :  
JDK-6751338 - ZIP inflater/deflater performance
Relates :  
JDK-6364346 - GZIPOutputStream is slower on 1.4.2_11-b02 than on 1.4.2_09
Relates :  
JDK-6348045 - REGRESSION: serious performance degradation as GZIPInputStream is slower
Description
Performance of Deflater.jvaa (and possibly also Inflater.java) could be improved, by "moving" concepts in DeflaterOutputStream.java

Work done on behalf of 6206933, 6348045, and 6364346 change the way that user data is accessed by native code.  6206933 changed access from pinning-during-flating to copy-then-flate.  This was undone in 6348045, because of the high cost of copying.  6206933 was subsequently re-done, with the intent of minimizing the amount of copying.  This was not good enough, and 6364346 was filed.

The fix for 6364346 is in DeflaterOutputStream, and satisfies the customer requirements.  However, users of Deflater will not gain from that performance.  The fix in DeflaterOutputStream should be "moved" to Deflater.

Similar performance improvements should be considered for Inflater as well.
Comments
SUGGESTED FIX The fix to 6364346 is such that if the length of the user data buffer given to write(byte[], int, int) is longer than the size of the Deflater's buffer, then the user data buffer is "chunked" into Deflater-buffer-size chunks. This is inefficient when using compression, because almost certainly N bytes of user data will compress to M bytes, and N > M. So upon each invocation of the compressor, the Deflater buffer will not be filled, resulting in more invocations of deflateBytes than necessary. But (simple) attempts to increase the size of the "stride" (see DeflaterOutputStream) have not shown a performance advantage, though the approach seems promising. It is possible that the idea of proceeding in strides could be moved from DelfaterOutputStream to deflateBytes, effectively bypassing Deflater.java. This would still require careful coordination of changes with Deflater.java, since deflateBytes manipulates fields in Deflater.java.
17-03-2006