前9000万个数字约占761MB,输出为：
seq 90000000
根据man parallel,它可以通过切断输入并使用不同的cpu压缩块来加速gzip的归档大文件.所以即使gzip是单线程的,这种技术也使它成为多线程的：
seq 90000000 | parallel --pipe --recend '' -k gzip -9 >bigfile.gz
在Intel Core i3-2330M(4)@ 2.2GHz上花了46秒.
管道到普通的旧gzip：
seq 90000000 | gzip -9 > bigfile2.gz
在相同的cpu上花了80秒.现在惊喜：
ls -log bigfile*.gz
输出：
-rw-rw-r-- 1 200016306 Jul 3 17:27 bigfile.gz -rw-rw-r-- 1 200381681 Jul 3 17:30 bigfile2.gz
300K更大？这看起来不对.首先,我检查了zdiff文件是否具有相同的内容 – 是的,相同.我认为任何压缩器在连续数据流方面都会比分块数据流做得更好.为什么bigfile2.gz不比bigfile.gz小？
解决方法
通过在deflateInit2()中使用zlib的memLevel参数,可以为每个块设置更小的块大小,从而做得更好.在这里,我每次使用7到2的memLevel值在单个线程中压缩相同的输出,其中较小的memLevel是较小的deflate块大小(请注意,zlib在默认级别上比gzip稍微好一点)：
> 9 – 199688429
> 8 – 198554111(默认)
> 7 – 191582070
> 6 – 184880482
> 5 – 181295029
> 4 – 180137425(此输入的最佳值)
> 3 – 181176610
> 2 – 185759115
此数据的最佳memLevel为4,压缩数据比默认memLevel为8小12 MB(9％).对于memLevel 8,deflate块大小为16383个符号,而对于memLevel 4,放气块大小为1023个符号.一个符号是文字字节或匹配.
改进来自输入的极其规则的性质,导致规则的匹配和文字命令序列.块大小越小,出现的这些不同命令就越少,然后它们需要更少的位来对每个命令进行编码.对于memLevel 3来说,这仍然是正确的,但到那时,每个deflate块开头的代码描述的开销取消了较少的不同代码的改进.
zopfli是一个deflate压缩器,它优化了块大小和所选命令,并设法将其压缩为100,656,812字节.虽然花了三个半小时！使用压缩级别11使用pigz调用zopfli.
