On Mon, 2010-02-15 at 22:15 +0100, Pierre Schmitz wrote:
Am Montag, 15. Februar 2010 19:36:41 schrieb Jan de Groot:
if not it's not an improvement and we should think about pbzip that now supports tar interaction and pipes!
Depends on the compression level. It's slower than gzip compression, but faster than bzip2 if you don't select the highest compression level. I guess you'll save more time uploading an xz-compressed openoffice package than you'll lose by compressing it with that.
Indeed. E.g. I just compiled Qt and package size went down from 34 MB to 25 MB. This saves me about 10 MByte upload for each arch. I didn't note any massive increase in compression time compared to compile and upload time.
Sure there are edge cases like big icon packs which wont compress well anyway. But in general the benefit of the way smaller packages is rally worth it. And you don't have to forget that you only compress a package once; but it's uploaded and downloaded many, many times.
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. Note that tighter compressions needs a bigger dictionary size when unpacking, which can be crap on low-memory systems.