Compression 为什么bzip2'；最大块大小900k？

bzip2

（即Julian Seward）列出了100k到900k之间的可用块大小：

 $ bzip2 --help
 bzip2, a block-sorting file compressor.  Version 1.0.6, 6-Sept-2010.

 usage: bzip2 [flags and input files in any order]

   -1 .. -9            set block size to 100k .. 900k

此数字对应于写入压缩文件中的

hundu k\u blocksize

值

从中，内存要求如下所示：

Compression:   400k + ( 8 x block size )

Decompression: 100k + ( 4 x block size ), or
               100k + ( 2.5 x block size )

在最初的程序编写时（1996年），我想760万（400k+8*900k）可能是计算机上的一个巨大内存量，但对于今天的机器来说，这算不了什么

我的问题分为两部分：

1） 块大小越大，压缩效果越好吗？（我天真地认为是的）。有什么理由不使用较大的块吗？压缩的cpu时间如何随块的大小缩放

2） 实际上，是否存在允许较大块大小的bzip2代码分叉（或替代实现）？这是否需要对源代码进行重大修改

---

文件格式似乎足够灵活，可以处理这个问题。例如由于

hundu k_blocksize

包含一个指示块大小的8位字符，因此可以向下扩展以指示更大的块大小（例如，

：“

=

x3A

=>

1000k

，

”；“

=

x3B

=>

1100k

，

”马特·马奥尼（Matt Mahoney）根据其大型文本压缩基准编译的程序支持了您的直觉，即更大的块大小应该会导致更高的压缩比gram，BBB，（）的压缩比提高了约40%，从块大小10^6到10^9。在这两个值之间，压缩时间加倍。现在使用的“xz”程序是LZ变体（称为LZMA2）最初由7zip作者Igor Pavlov描述，作为压缩源代码的默认策略，bzip2开始取代bzip2，值得研究提高bzip2块大小的可能性，看看它是否是一个可行的替代方案。此外，bzip2避免了算术编码，因为专利限制已经过期。结合h使用Jarek Duda开发的用于熵编码的快速非对称数字系统的可能性，现代化的bzip2在压缩比和速度与xz方面都很有竞争力