> Obviously it's not impossible, since it's happening on my laptop. Well, zstd cli is more optimized for multithreading and asynchrounous i/o. zstd is overlappi

> Obviously it's not impossible, since it's happening on my laptop. Well, zstd cli is more optimized for multithreading and asynchrounous i/o. zstd is overlapping cpu decompression with reading/writing. Additionally zstd compressed data is more dense. It's possible that on your notebook you have lz4 decompression including i/o slower that zstd. This is not the way lz are compared in general. Otherwise nobody will use lz4 anymore. > I haven't tried TurboBench, but this is what I get when running the built-in lz4 and zstd benchmarks You can see, even on your machine lz4 is faster than zstd. Now it's obvious that asynchrounous i/o + multithreading is making the difference in the cli case. > However, I don't understand exactly what this metric means. Does it mean that lz4 can ingest the input at ~4 GB/s or that it produces the output at ~4 GB/s? In data compression the metrics are always relative to the original uncompressed size. > But in any case, what matters to me as a user is how quickly I can compress and decompress a file. Well, this depends of the use case. I'm using 7zip (GUI) and it's working fine for me. It's very hard to make benchmarks when multithreading or i/o is involved. You'll get often different results on different hardware configurations and the number of threads.