Re: Linux Kernel Source Compression

Alistair John Strachan
2006-05-21T22:29:27Z

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.