bzip3

原文 ↗ Hacker News 讨论 ↗

bzip3 是一款受 bzip2 的 Burrows–Wheeler 变换启发的现代压缩器，因在某些高度重复的数据集上有时能在压缩率上击败 zstd 和其他流行格式而受到关注。评论者强调，它的优势高度依赖数据和参数，并指出一些已公布的基准测试具有误导性（例如窗口大小不匹配以及内存使用过大），还提到在一些真实测试中其解压开销非常高。围绕实际采用也存在争论——考虑到 zstd 强大的生态支持、bzip3 的许可证和命名选择，以及许多用户如今更重视快速、低内存的解压而非体积上的细微优势。

基准测试与公平性

  • 多位评论者批评官方基准测试过于粗糙，而且有“挑选性展示”的嫌疑。
  • 主要担忧包括：
    • bzip3 使用了非常大的块（例如 512 MB）进行测试，而 zstd 则保持默认的小窗口（约 8 MB），这会让 zstd 在重复性很强的语料（如拼接的源码树）上严重吃亏。
    • 内存使用没有统一标准化（例如 bzip3 需要约 12–18 GB RAM，而 zstd 少于 1 GB）。
    • 一些对比遗漏了更强的竞争者（例如 lrzip 测试中的 zstd）。
  • 当重新用匹配的长窗口（--long）运行 zstd 时，它的压缩率和速度都可能比报告中的结果好得多，有时甚至会以很大优势超过 bzip3。

真实世界性能与数据依赖性

  • 多个独立测试显示其表现高度依赖数据：
    • 在某些文件上，bzip3 的压缩率优于 zstd -19，且速度相当甚至更好。
    • 在另一些文件上，zstd 在体积上略胜一筹，并且在速度上明显更快。
  • 对于一个 Linux 内核树，报告称 bzip3 的解压速度比多核 zstd 慢约 145 倍，而压缩效果还略差。
  • 在 enwik9 文本语料上，bzip3 的压缩结果明显小于 zstd，但在解压时却消耗了数量级更多的内存和时间。

资源使用与实际用例

  • 一个反复出现的主题是：bzip3 可以达到令人印象深刻的压缩率，但解压可能极其缓慢且非常吃内存，尤其是在使用超大块时。
  • 有人建议它只适合“压缩一次、解压多次”的场景，并且最好先按文件单独调参。
  • 另一些人则认为，与现代替代方案相比，它在总体基准测试中的表现“并不算特别令人印象深刻”。

替代方案与生态系统

  • zstd 被反复描述为当前通用压缩器的首选：可调性很强、解压速度快、压缩率不错，并且支持广泛（文件系统、数据库等）。
  • 针对 JSONL 日志的基准测试显示，bzip3 的压缩率最好，但 CPU 时间高得多；在默认设置下，zstd 的体积几乎和 gzip 一样小，但速度远超其他所有方案，而且还有调参空间。

可靠性、许可证与命名

  • “数据可能无法恢复”的强警告让一些人感到担忧，但也有人指出 bzip2、xz 以及常见开源许可证中都存在类似免责声明。
  • 有些人不喜欢重用“bzip3”这个名字，以及从 bzip2 的宽松许可证转为 LGPL；也有人认为命名和许可证选择都属于作者的权利。

未来方向

  • 讨论中提出了一些想法：可自动为不同区域选择算法的多流归档、基于 ML/agent 的参数优化，以及对压缩器正确性的形式化验证，不过后者被认为极其困难。