United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6399199 : Improve performance of Deflater

Details
Type:
Enhancement
Submit Date:
2006-03-16
Status:
Open
Updated Date:
2014-01-16
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
generic
Sub-Component:
java.util.jar
CPU:
generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
6
Targeted Versions:

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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.
                                     
2006-03-17



Hardware and Software, Engineered to Work Together