gzip_wrapper: fix nasty speed/compression regression
Final pre-release tests threw up an odd regression in compression
and speed with the gzip_wrapper.c code. Sample filesystem compression
was ~0.025% (or 1Mbyte extra per 4Gbytes of compressed data) worse
than the previous Mksquashfs 4.2.
A git bisect rather unexpectedly narrowed the culprit down to this
line in gzip_wrapper.c
res = deflateInit2(stream, compression_level, Z_DEFLATED,
window_size, 9, Z_DEFAULT_STRATEGY);
This replaced the equivalent
res = deflateInit(stream, compression_level);
When the gzip_wrapper code was extended to allow the window_size
used in compression to be changed.
The culprit in the line is the 9, which is the amount of memory
deflate uses to compress the data. I took advantage of the fact
that deflateInit2() allows one to increase the memory usage from the
default of 8 (used by deflateInit()) to the maximum of 9. As explained
by the comments in zlib.h, this is supposed to increase speed.
From zlib.h
" The memLevel parameter specifies how much memory should be allocated
for the internal compression state. memLevel=1 uses minimum memory but is
slow and reduces compression ratio; memLevel=9 uses maximum memory for
optimal speed. The default value is 8. See zconf.h for total memory usage
as a function of windowBits and memLevel. "
It in fact appears from my tests that increasing the value from 8 to 9
both reduces compression and reduces speed too. This is probably
a bug in zlib ...
Using the default value of 8, rather than 9, fixes the small compression
and speed regression observed.
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
1 file changed