On 2015-12-03 07:09, Imran Geriskovan wrote:
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.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.
smime.p7s
Description: S/MIME Cryptographic Signature
