以前のエントリでは、文献をベースに圧縮アルゴリズムの違いを一覧化したが、この度、Windows Subsystem for Linux がようやく一般公開されたので、その環境上で実際に各種圧縮プログラムでの圧縮効率を実測してみた。
データとして使ったのは、郵便番号ダウンロードの全国一括データ(約12MB)。容量的にはたいしたことはないけれども、18種類の圧縮プログラムを10回実行し平均を取るとなると結構な時間がかかる。
値は前回と同じく gzip を基準に正規化したものを記載している(ちなみに gzip 圧縮後サイズは、約1.8MB で 15%ほどのサイズに圧縮されている)。
圧縮プログラム | 圧縮後 サイズ | 圧縮時間 | 圧縮時 最大メモリ量 | 伸張時間 | 伸長時 最大メモリ量 |
---|---|---|---|---|---|
lzip(best) | 0.69 | 31.40 | 164.17 | 2.61 | 17.47 |
xz | 0.69 | 23.68 | 106.96 | 2.45 | 12.24 |
lzip | 0.71 | 19.44 | 102.77 | 2.58 | 12.43 |
brotli | 0.72 | 94.01 | 72.48 | 0.63 | 7.31 |
bzip2 | 0.79 | 4.22 | 7.97 | 5.19 | 5.62 |
xz(fast) | 0.85 | 1.67 | 4.05 | 2.50 | 1.66 |
zopfli | 0.89 | 2191.20 | 75.25 | 1.00 | 1.00 |
gzip(best) | 0.95 | 6.33 | 0.96 | 1.02 | 1.00 |
lzip(fast) | 0.97 | 3.24 | 14.47 | 2.63 | 2.87 |
gzip | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 |
lzfse | 1.00 | 1.70 | 30.17 | 0.66 | 24.88 |
gzip(fast) | 1.18 | 0.47 | 1.00 | 1.14 | 1.00 |
lzop(best) | 1.21 | 12.08 | 1.84 | 0.36 | 1.20 |
lz4(best) | 1.29 | 1.38 | 6.52 | 0.34 | 7.31 |
snappy | 1.49 | 0.21 | 1.39 | 0.41 | 1.61 |
lzop | 1.50 | 0.16 | 1.44 | 0.44 | 1.20 |
lzop(fast) | 1.50 | 0.14 | 1.59 | 0.47 | 1.20 |
lz4 | 1.61 | 0.22 | 6.37 | 0.25 | 7.57 |
こうしてみると、総合的に gzip のバランスの良さが目立つ。圧縮率も速度もメモリ量もそこそこというのは使い勝手を考えると大きなメリットだ。
圧縮率を重視するなら、LZMA 系の lzip, xz が優勢となる。圧縮速度、メモリ量などを考えると lzip よりも xz の方がよいように見える。
伸張速度を重視するなら、はやりの lz4 がやはり良いようだが、メモリ消費が激しいので、そのような用途では lzop や snappy の方が良いかもしれない。ただ、今回は試していないが、 lz4 もストリーム圧縮に対応したようなので、ライブラリを使えば回避できるかもしれない。
最近の圧縮アルゴリズムのはやりは、Web でのダウンロードを想定し、圧縮率と伸張速度を重視したものが増えている。たしかにその用途では brotli は魅力的に見える。gzip 互換の zopfli も魅力的ではあるが、1割の圧縮率向上のために2000倍の圧縮速度低下を受け入れるのはなかなか厳しい物がある。Apple の新圧縮アルゴリズム lzfse も今回計測対象に入れてみたが、圧縮率は gzip 並、圧縮速度もそう悪くなく、伸張は速いという特徴なので、どちらかと言うとストレージのリアルタイムでの圧縮・伸張が想定されているのかもしれない。
前回も書いたけれども、いずれの圧縮プログラム/アルゴリズムとも特徴があり、きちんと用途に応じたものを選ぶ必要があるのだ、ということを改めて感じた次第。