Theme 1 – Benchmark fairness and cherry‑picking concerns
Many commenters argued that the reported bzip3 advantage relies on unfair settings (e.g., a 512 MB block size vs. zstd’s default 8 MB window) and on selectively chosen data.
“The benchmarks are disingenuous, to the point of looking cherry‑picked. The block size for bzip3 is set to 512 MB, but the window size for zstd is left to its default (8 MB I believe for high levels).” – ot
“Even if the examples are highly cherry‑picked, it is quite suprising to me that such pareto‑dominance is possible at all.” – myrmidon
Theme 2 – Data‑dependent performance unpredictability
Several users noted that bzip3’s results vary wildly with input; it can beat zstd on some files but lose on others, making it hard to predict without trial compression.
“The problem was that without doing a compression there was no way to guess whether a file would be among those preferred by bzip3 or by zstd or by xz.” – adrian_b
“Compression performance vs ‘zstd -19’ seems to depends a lot on actual input data in a very unpredictable way.” – myrmidon
Theme 3 – Practical adoption, support, and licensing issues
Discussion highlighted real‑world barriers: limited tool support, parallel decompression quirks, licensing (LGPL vs. permissive), and the need for heuristics or multi‑stream formats to be useful.
“I ended up using gzip because it's best supported by the software I use and most likely to have support in software I adopt.” – 8organicbits
“zstd is the go-to compression format these days. It's even supported in low-level software such as many linux filesystems.” – nvme0n1p1
“DO NOT COMPRESS ANY DATA WITH THIS PROGRAM UNLESS YOU ARE PREPARED TO ACCEPT THE POSSIBILITY, HOWEVER SMALL, THAT THE DATA WILL NOT BE RECOVERABLE.” – sergiotapia (quoting the bzip3 warning)