[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Something like nocompress DEB_BUILD_OPTION



On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote:
> On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote:
> Okay. I did some tests with various packages. From binary only to text
> only. 

Thanks for the tests Bastian. It would still be nice to see a bigger
sample, if the tests only consisted of these 4 packages, though.

> Package                   | gzip -6  | gzip -9  | gzip | xz -1
> --------------------------+----------+-----------------+---------
> libc6                     |  4339010 |  4321933 | 0.5% |  2938132
> perl-modules              |  3874170 |  3822719 | 1.5% |  3248392
> gnome-user-guide          |  9217494 |  9172395 | 0.5% |  7589076
> linux-image-3.2.0-4-amd64 | 32928159 | 32522228 |      | 25945856
> 
> "gzip -9" is always much slower then "gzip -6". It is at most 2% better.
> "xz -1" is usualy faster then "gzip -9" and much better. However most
> packages only needs seconds to compress, so the difference will no
> really matter.
> 
> So instead of switching to gzip -6, a switch to xz -1 would make more
> sense in term of size and also speed.

> So my proposal would be:
> - Don't do anything for Wheezy.
>   Any change may break the CD creation.
> - Switch to xz per default for Jessie.
>   xz -3 is often faster in compressing stuff then gzip -9. -6 needs a
>   lot of memory, especially for compressing the files, so reducing the
>   default to -3 may make sense and does not cost much.

I've already mentioned in some other thread that for dpkg 1.17.x (that
is after wheezy), I'll be switching dpkg-deb to xz as the default
compressor, as that seemed the consensus; but that does not mean that
if the default compression level for gzip is suboptimal (as it seems
it is), that cannot be changed too.

For changing xz default compression level I'd like to see the
implications on a wider dataset, also we should take into account that
compression is only done once, so I don't think that's such an issue,
if the time and memory are not really onerous.

Thanks,
Guillem


Reply to: