BZip3：BZip2 的精神继承者
BZip3 是 BZip2 的精神继承者，在压缩率和性能上实现了显著突破。它通过 order-0 context mixing entropy coder、基于后缀数组的快速 Burrows-Wheeler 变换以及结合 LZ77 风格字符串匹配和 PPM 风格上下文建模的 RLE 技术，大幅提升了压缩效率。在 Perl 源代码压缩测试中，BZip3 的压缩体积远小于 xz、bzip2 和 Zstandard，同时解压速度也表现优异。尽管性能高度依赖编译器，但其在文本和代码压缩方面的卓越表现使其成为值得关注的工具。
BZip3 在压缩文本或代码方面表现出色，就像它的祖先一样。
HN 评论区
122- altairprime
之前的讨论：
“嗨，我是工具作者。”关于 bzip3 中使用的 Burrows-Wheeler 变换的有用解释：https://news.ycombinator.com/item?id=42902407
“bzip3 尚未列入大型文本压缩基准测试”现在已列入：https://mattmahoney.net/dc/text.html
(2 年前，176 条评论) https://news.ycombinator.com/item?id=42899713
(4 年前，104 条评论) https://news.ycombinator.com/item?id=31324439
- 8organicbits
我最近在处理压缩的 .jsonl 文件（JSON Lines 格式）。我发现 lzma 的压缩效果比 gzip 或 bzip2 好得多，这有助于降低归档成本，但使用起来很有挑战性，因为软件支持不足。我使用 duckdb 进行处理，它透明支持 gzip。有一个 bzip2 扩展，但没有 lzma 或 bzip3 的扩展。
我最终选择了 gzip，因为它的软件支持最好，而且我将来采用的软件最有可能支持它。但它在我尝试的选项中压缩效果最差。这些 bzip3 的数据确实让我产生了错失恐惧症（FOMO）……
- ot
这些基准测试很不诚实，甚至看起来像是精心挑选的。bzip3 的块大小设置为 512MB，但 zstd 的窗口大小保留为默认值（我认为是高压缩级别下的 8MB）。因此，在这个由所有版本的 Perl 源代码拼接而成的语料库中，窗口太小，无法看到所有相同的文件并进行匹配。
此外，由非常长的重复内容组成的语料库几乎是对基于 BWT 的压缩器最有利的情况。
如果我们将 zstd 的窗口大小调整为与 bzip3 相同，结果会有显著不同：
% gzcat *.gz | time zstd -T8 -16 | wc -c # 基准
2819113884
zstd -T8 -16 2054.50s user 3.47s system 783% cpu 4:22.80 total
% gzcat *.gz | time zstd -T8 -16 --long=29 | wc -c
196405076
zstd -T8 -16 --long=29 1083.06s user 2.41s system 783% cpu 2:18.55 total
比基准小了近 15 倍，比 bzip3 小了两倍多，而且 CPU 时间减半（因为长匹配更早被发现，所以工作量更少）。
（基准数字略有不同，因为我没有使用作者使用的确切 Perl 版本集）
此外，在使用 lrzip 的基准测试中，窗口大小的相关性会降低，但 zstd 甚至没有被比较。
- JdeBP
一个有趣的非故意基准测试是去 https://github.com/iczelia/bzip3/releases 看看 bzip3 对其自身发布归档文件的压缩程度；然后去 https://github.com/iczelia/bzip3/blob/master/.github/workflo... 看看这里为其他压缩器选择了哪些选项。
- CodesInChaos
我认为应该包含使用更大窗口和长距离模式的 zstd 的基准测试。我不惊讶于他们使用的窗口比单个版本 tar 文件还小，这会阻止有效的压缩。
- amelius
> 然而，算法的复杂性，特别是代码中存在各种发生概率极低但非零的特殊情况，使得无法排除程序中仍可能存在错误的可能性。
听起来这或许是形式化 + AI 的一个不错的测试用例？
- whatever1
我认为压缩算法非常适合利用 LLM 进行重大改进。这是一个理想的闭环评估问题，你可以让代理（agent）自由尝试各种方法。
- BorisMelnik
现在比 gzip 快了吗，还是仍然更慢？（抱歉我没读 readme）