3 ms·
There are basically three scenarios where I choose various compression algorithms (a few exceptions excluded): - maximum compatibility (while tolerating low pe
by drej 7y ago
There are basically three scenarios where I choose various compression algorithms (a few exceptions excluded):
- maximum compatibility (while tolerating low performance) - gzip
- great performance (while tolerating larger files) - snappy
- very good performance with good (not best) compression ratios - zstd
I don't really want to use Any New Shiny Algo to compress some data that might outlive this piece of software, that's why I use gzip very often, because I know I'll always be able to decompress it. But I've been increasingly adopting zstd and snappy for one single reason - they are becoming widely supported within the ecosystems I work in (data processing).
That, to me, is more important than compression ratios and decompression speeds.
- d33 7y agoHow does snappy compare to lz4? Also, for gzip, you might want to consider using its multithreaded version, called "pigz".
- terrelln 7y agolz4 compresses and decompresses faster than snappy, and compresses similarly. You can see some comparisons on the GitHub's readme https://github.com/lz4/lz4 https://github.com/lz4/lz4.
- coldpie 7y agoStrangely, snappy doesn't seem to ship a binary on Arch Linux, just a shared library. Is there no snappy command-line program?