> Does LZMA have any drawbacks? According to Wikipedia[1,2] indicates that > it is slower than gzip, at perhaps around half the speed, but that it > may require a lot of memory to compress, but reasonably little to > decompress.
According to my check last year and a few weeks or months: http://www.linuks.mine.nu/sizematters/ lzma decompresses faster than bzip2. yes it's slower to compress, but which user will have to? > Gürkan, do you have numbers on compression speed and memory usage for > the Debian archive? please see the above link. > I'm not sure if the smaller size that LZMA allows is worth it if it then > takes a lot longer to unpack files, or if it becomes impossible to do so > due to memory requirements. i don't know on memory requirements. but i didn't notice any speed drawbacks for my personal use. > However, it should be possible to use > different compressors on different architectures: if LZMA turns out to > be too slow for arm, for example, we could stick with gzip on arm and > other slow/small architectures, and use LZMA on the fast/big ones. have you done some testing or is this just a guess? > It is far less deployed as bzip2, so manually unpacking .deb packages on > some random GNU/Linux or Unix rescue system is more likely to fail. very seldom i had the need to manually unpack .deb packages. and lzma can easily be installed, jus tlike bzip2 (which is not found by default on any to me known system). > Bzip2 is pretty ubiquitous these days, so comparing lzma numbers to > bzip2 might make sense as well. see the url above. guerkan
