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
この数値は、圧縮ファイルのヘッダー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) というメモリはコンピューター上でかなりの量だったかもしれないと思いますが、今日のマシンではそんなことはありません。
私の質問は2つの部分です：
1) ブロック サイズを大きくすると、圧縮率が向上しますか? （単純に、私はイエスだと思います）。大きなブロックを使用しない理由はありますか? 圧縮の CPU 時間は、ブロックのサイズに応じてどのように変化しますか?
2) 実際には、より大きなブロックサイズを可能にする bzip2 コード (または代替実装) のフォークはありますか? これには、ソース コードの大幅な修正が必要ですか?
ファイル形式は、これを処理するのに十分な柔軟性があるようです。たとえば...hundred_k_blocksizeブロックサイズを示す8ビット文字を保持しているため、ASCIIテーブルを下に拡張して、より大きなブロックサイズを示すことができます(例':'= x3A=> 1000k、';'= x3B=> 1100k、'<'= x3C=> 1200k、...) .