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.
