Re: compression disk space saving - what are your results?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

On 2015-12-03 07:09, Imran Geriskovan wrote:
>>> On a side note, I really wish BTRFS would just add LZ4 support.  It's a
>>> lot more deterministic WRT decompression time than LZO, gets a similar
>>> compression ratio, and runs faster on most processors for both
>>> compression and decompression.
>
> Relative ratios according to
> http://catchchallenger.first-world.info//wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO
>
> Compressed size
> gzip (1) - lzo (1.4) - lz4 (1.4)
>
> Compression Time
> gzip (5) - lzo (1) - lz4 (0.8)
>
> Decompression Time
> gzip (9) - lzo (4) - lz4 (1)
>
> Compression Memory
> gzip (1) - lzo (2) - lz4 (20)
>
> Decompression Memory
> gzip (1) - lzo (2) - lz4 (130). Yes 130! not a typo.
>
> But there is a note:
> Note: lz4 it's the program using this size, the
> code for internal lz4 use very less memory.
>
> However, I could not find any better apples to apples
> comparison.
>
> If lz4's real memory consumption is in orders of lzo,
> than it looks good.
AFAICT, it's similar memory consumption.  I did some tests a while back 
comparing the options for kernel image compression using a VM, and one 
of the things I tested (although I can't for the life of me remember how 
exactly except that it involved using QEMU hooked up to GDB) was 
run-time decompressor footprint.  LZO really should have a smaller 
memory footprint too, it's just that lzop needs to handle almost a dozen 
different LZO compression formats.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]