proposal to optimise the performance of the Jar utility
mike.duigou at oracle.com
Thu Apr 14 00:02:10 UTC 2011
On Apr 13 2011, at 16:22 , Xueming Shen wrote:
> On 04-13-2011 3:00 PM, Mike Duigou wrote:
>> Mike, can you share the results of performance testing at various compression levels? Is there much difference between the levels or an apparent "sweet spot"?
>> For low hanging fruit for jdk 7 it might be worth considering raising the default compression level from 5 to 6 (the zlib default). Raising the level from 5 to 6 entails (by today's
> Hi Mike,
> zlib1.2.3/zlib.h states the default is level 6. I've not checked or run any test to verify if its
> implementation matches its docs, any reason you think zlib actually is using level 5 as
> default? I can take look into it further...
I was basing this on Mike Skells' earlier posting:
>>>> 1. Allowing the Jar utility to have other compression levels (currently it
>>>> allows default (5) only)
If it's using Z_DEFAULT_COMPRESSION then it's actually using 6 as you suggest.
Sorry for the confusion.
> ZEXTERN int ZEXPORT deflateInit OF((z_streamp strm, int level));
> Initializes the internal stream state for compression. The fields
> zalloc, zfree and opaque must be initialized before by the caller.
> If zalloc and zfree are set to Z_NULL, deflateInit updates them to
> use default allocation functions.
> The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9:
> 1 gives best speed, 9 gives best compression, 0 gives no compression at
> all (the input data is simply copied a block at a time).
> Z_DEFAULT_COMPRESSION requests a default compromise between speed and
> compression (currently equivalent to level 6).
More information about the core-libs-dev