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.