Re: Linux Kernel Source Compression

[Alistair John Strachan <s0348365@sms.ed.ac.uk>]

On Sunday 21 May 2006 23:22, Sam Vilain wrote:
[snip]
> Interesting.  Googling a bit;  from http://tukaani.org/lzma/benchmarks:
>
> In terms of speed, gzip is the winner again. lzma comes right behind it
> two to three times slower than gzip. bzip2 is a lot slower taking
> usually two to six times more time than lzma, that is, four to twelve
> times more than gzip. One interesting thing is that gzip and lzma
> decompress the faster the smaller the compressed size is, while bzip2
> gets slower when the compression ratio gets better.
> [...]
> neither bzip2 nor lzma can compete with gzip in terms of speed or memory
> usage.
>
> Also this:
>
> "lzmash -8" and "lzmash -9" require lots of memory and are practical
> only on newer computers; the files compressed with them are probably a
> pain to decompress on systems with less than 32 MB or 64 MB of memory.
> [...]
> The files compressed with the default "lzmash -7" can still be
> decompressed, even on machines with only 16 MB of RAM

Interesting info. I agree that LZMA is not a replacement for gzip/zlib, 
because gzip is extremely size/time efficient.

However, as noted in another thread, it is almost certainly a viable 
replacement for bzip2, since people that use bzip2 are generally interested 
in a size optimisation, not a compression speed one, and even if compression 
speed is relevant, LZMA's options scale to be approximately as good (or as 
bad??) as bzip2.

This is all fairly academic. I think the issue still boils down to widespread 
adoption; bzip2 took a while to get off the ground, people don't like messing 
with new formats, and distributors have to pick up the tools.

I think kernel.org switching formats would be one of the last things that 
could, or indeed should, happen.

-- 
Cheers,
Alistair.

Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.