If you want to see a comparison against an even broader set of open source compression algos, this is lzbench (it's linked directly from the ZXC github page)
lzbench has added ZXC to its suite. This makes a nice apples to apples comparison possible.
> Unlike symmetric codecs (LZ4), ZXC trades compression speed (build-time) for maximum decompression throughput (run-time).
Huh? This is exactly what lz4 does. Yes, zxc is faster than lz4 at decompressing, but lz4 is clearly asymmetric in the benchmarks shown further down on the page.
Fair point regarding the terminology. You are right that LZ4 is already asymmetric compared to generic compression.
My phrasing was a bit too binary. What I meant to highlight is that ZXC pushes this trade-off much further than LZ4. I designed ZXC specifically for scenarios where we accept a significantly slower build-time/compression cost in exchange for that extra raw decode throughput.
I think the existence of lz4hc is evidence that what you are discussing is within the design-space of LZ4, but ZXC just did a better job of it (though lz4hc achieves better compression than ZXC)
And afaik this is what most compression algorithms do. It’s certainly one of the trade offs you have to consider when archiving at high levels of compression.
If you want to see a comparison against an even broader set of open source compression algos, this is lzbench (it's linked directly from the ZXC github page)
lzbench has added ZXC to its suite. This makes a nice apples to apples comparison possible.
https://github.com/inikep/lzbench
> Unlike symmetric codecs (LZ4), ZXC trades compression speed (build-time) for maximum decompression throughput (run-time).
Huh? This is exactly what lz4 does. Yes, zxc is faster than lz4 at decompressing, but lz4 is clearly asymmetric in the benchmarks shown further down on the page.
Fair point regarding the terminology. You are right that LZ4 is already asymmetric compared to generic compression.
My phrasing was a bit too binary. What I meant to highlight is that ZXC pushes this trade-off much further than LZ4. I designed ZXC specifically for scenarios where we accept a significantly slower build-time/compression cost in exchange for that extra raw decode throughput.
I think the existence of lz4hc is evidence that what you are discussing is within the design-space of LZ4, but ZXC just did a better job of it (though lz4hc achieves better compression than ZXC)
And afaik this is what most compression algorithms do. It’s certainly one of the trade offs you have to consider when archiving at high levels of compression.