This is great. But please note, some of the graphs presented use a common statistics cheat of logarithmic scale along one or more of the axis. Many times, lz4

This is great. But please note, some of the graphs presented use a common statistics cheat of logarithmic scale along one or more of the axis. Many times, lz4 level 1 isn't just 25% faster [0] in Compression vs. say zlib level 1 (as it appears visually), it's actually 6 times (6x, or 600%) faster in terms of MB/s (~600 MB/s vs. ~100 MB/s)! And it's not just 5% or so faster than zstd in Decompression (visually) [1], it's about twice as fast (~2000 MB/s vs. ~1000 MB/s). Yes. It does not compress as well. But ~3.2:1 compression ratio best case for lz4 (listed as ~3.2 in the chart) compresses almost as quickly as the 6:1 zstd [0] but will then decompress twice as fast as zstd at any level [1]. Having a high-compression is a case I could (almost) not care about. If you're youtube/google or facebook/instagram, you might care (streaming, photos, static assets all at enormous scales). For me, however, the above results mean far less CPU burden on the client with a twice the burden on the network I/O. If you're concerned about battery, loading screens, or download dialogs, I'd still pick lz4. Just turn the AC up a half notch in my AWS DC. [0] http://gregoryszorc.com/images/compression-bundle-common.png http://gregoryszorc.com/images/compression-bundle-common.png [1] http://gregoryszorc.com/images/decompression-bundle-output.png http://gregoryszorc.com/images/decompression-bundle-output.p...