bzip2
(即 Julian Seward 的 this program)列出了 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
此数字对应于写入压缩文件 header 的
hundred_k_blocksize
值。从 documentation 开始,内存要求如下:
Compression: 400k + ( 8 x block size )
Decompression: 100k + ( 4 x block size ), or
100k + ( 2.5 x block size )
在编写原始程序时(1996 年),我想 7.6M(400k + 8 * 900k)在计算机上可能是一个很大的内存量,但对于今天的机器来说,这算不了什么。
我的问题是两部分:
1) 更大的块大小会实现更好的压缩吗? (我天真地认为是的)。有什么理由不使用更大的块吗?压缩的 cpu 时间如何与块大小成比例?
2) 实际上,是否存在允许更大块大小的 bzip2 代码(或替代实现)的任何分支?这是否需要对源代码进行重大修改?
文件格式似乎足够灵活来处理这个问题。例如...因为
hundred_k_blocksize
モ8位字符指示所述块大小,人们可以向下延伸ASCII table以指示较大块尺寸(例如':'
= x3A
=> 1000k
,';'
= x3B
=> 1100k
,'<'
= x3C
=> 1200k
,...)。
最佳答案
您的直觉是,更大的块大小应该导致更高的压缩率,这一点得到了 Matt Mahoney 从他的大文本压缩基准程序中编译的程序的支持。例如,开源 BWT 程序 BBB ( http://mattmahoney.net/dc/text.html#1640 ) 的压缩率提高了约 40%,从 10^6 到 10^9 的块大小。在这两个值之间,压缩时间加倍。现在使用的“xz”程序是一个 LZ 变体(称为 LZMA2),最初由 7zip 的作者 Igor Pavlov 描述,开始取代 bzip2 作为压缩源代码的默认策略,值得研究提升 bzip2 的可能性块大小,看看它是否可能是一个可行的替代方案。此外,由于专利限制,bzip2 避免了算术编码,这些限制已经过期。结合 Jarek Duda 开发的使用快速非对称数字系统进行熵编码的可能性,现代化的 bzip2 可以在压缩比和速度上与 xz 非常有竞争力。
关于compression - 为什么 bzip2 的最大块大小是 900k?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48679452/