[arch-dev-public] [PATCH] Support xz compressed packages

[Jan de Groot]

On Tue, 2010-02-16 at 11:21 +0100, Pierre Schmitz wrote:
> Am Dienstag, 16. Februar 2010 08:51:50 schrieb Jan de Groot:
> > What's the compression rate used in your test? I've seen benchmarks for
> > an older version of xz-utils (I think it was called lzma-utils). In that
> > benchmark the most simple compression level was faster and smaller than
> > gzip -9, and bzip2 was outperformed anyways.
> 
> I just used the default which should be -6.
> 
> > Note that tighter compressions needs a bigger dictionary size when
> > unpacking, which can be crap on low-memory systems.
> 
> Do you have numbers? We could do some testing in qemu with e.g. 128MB RAM 
> etc.. Or maybe have a look at Slackware who are already using xz for their 
> whole repo. According to them you need at least a 486 and 64MB RAM. Does not 
> look like anything we should worry about.

Did some testing with openoffice-base 3.2.0-1-x86_64.tar:
compression speed:
gzip:  0m28.945s
bzip2: 1m21.876s
xz -1: 0m49.244s
xz -2: 1m18.444s
xz -3: 3m34.208s
xz -6: 4m41.148s

decompression speed:
gzip:  0m 5.772s
bzip2: 0m29.433s
xz -1: 0m13.983s
xz -2: 0m12.949s
xz -3: 0m12.706s
sz -6: 0m11.462s

size:
tar:   370728960
gzip:  173262975
bzip2: 165765469
xz -1: 157099460
xz -2: 150147496
xz -3: 142961984
xz -6: 129979708

For decompression, it doesn't matter so much which xz level you choose.
For compression, anything beyond -2 is painfully slow. These times are
measured on a Core2Duo E4500 by compressing the single tar file. Note
that -6 saves a whopping 20MB over compressing with -2, but whatever we
choose is always better than gzip or bzip2.