proposal to optimise the performance of the Jar utility

[Mike Duigou]

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.

Mike

> ...
> 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).
> ...