On Thu, 2013-05-09 at 00:42 +0200, Bastian Blank wrote: > On Wed, May 08, 2013 at 11:13:59PM +0200, Adam Borowski wrote: > > On Wed, May 08, 2013 at 06:14:36PM +0200, Bastian Blank wrote: > > > On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote: > > > > As mentioned some months ago [0], I'm planning to switch dpkg-deb default > > > > compressor from gzip to xz, as there seemed to be consensus that was > > > > the way to go, and given the amount of already manually switched > > > > packages, or packaging helpers. :/ > > > > > > What about the compression level? xz -6 is pretty heavy and not needed > > > for 99% of the packages. -3 or even -2 or -1 are sufficient. > > > As my and Hideki's repacks of the archive show, special-casing small > > packages is a waste of time: gains are hardly below linear for any > > packages big enough to take longer than fork()ing the compressor. > > dpkg-deb does not fork the xz: > | $ objdump -x /usr/bin/dpkg-deb | grep liblzma > | NEEDED liblzma.so.5 > > > Quoting some data from 2011, all with xz -6: > > ] * A repack of the whole archive (amd64+all main, ~40GB) took close to three > > ] hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz). > > This doesn't add up to the numbers I have from real life packages. > linux-image-*-amd64-dbg, compressed size 250MiB, takes 20-30 minutes to > compress on an 61xx Opteron. [...] Yes, it takes about as long as the compilation (depending on number of cores) because compression is not parallelised. It still seems worthwhile when the debug info is so large, but I would like to see dpkg use a parallelised xz compressor when the parallel option is present in DEB_BUILD_OPTIONS. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison
Attachment:
signature.asc
Description: This is a digitally signed message part