圧縮
このパッケージは、さまざまな圧縮アルゴリズムを提供します。

変更ログ
-
2022年4月26日(v1.15.2)
-
2022年3月11日(v1.15.1)
-
2022年3月3日(v1.15.0)
詳細を見る
圧縮と解凍の両方で、「同期」ストリーム操作がサポートされるようになりました。これは、「並行性」が1に設定されている場合は常に、ゴルーチンを生成せずに動作することを意味します。
ゴルーチンの割り当てによりワークロードがはるかに効果的に分割されるため、非同期でのストリームの解凍が高速になりました。通常のストリームでは、これは通常、解凍に2つのコアを完全に使用します。ストリームのデコードが終了すると、ゴルーチンは残りません。そのため、デコーダーを安全にプールし、ガベージコレクションを行うことができます。
リリースは広範囲にわたってテストされていますが、アップグレード時にテストすることをお勧めします。
-
2022年2月22日(v1.14.4)
-
2022年2月17日(v1.14.3)
-
2022年1月25日(v1.14.2)
-
2022年1月11日(v1.14.1)
-
2021年8月30日(v1.13.5)
- gz / zlib / flate:エイリアスstdlibエラー#425
- s2:コマンドラインツールにブロックサポートを追加#413
- zstd:pooledZipWriterはライターを同じプールに戻す必要があります#426
- テスト#421の外部依存関係としてgolang/snappyを削除しました
-
2021年8月12日(v1.13.4)
-
2021年8月3日(v1.13.3)
- zstd:最高の圧縮を改善#404
- zstd:WriteToエラー転送#411を修正
- gzhttp:http.Handlerの代わりにhttp.HandlerFuncを返します。変化を壊す可能性は低い。#406
- s2sx:最大サイズエラー#399を修正
- zstd:リセット時にオプションのストリームコンテンツサイズを追加#401
- zstd:レベル> = 10の場合はSpeedBestCompressionを使用します#410
-
2021年6月14日(v1.13.1)
-
2021年6月3日(v1.13.0)
- HTTPサーバーとクライアントをGZIPコンプレッサーでラップできるgzhttpを追加しました。
- zstd:短い無効な署名を検出する#382
- zstd:必要な場合にのみデコーダーゴルーチンを生成します。#380
v1.12.xへの変更を参照してください
-
2021年5月25日(v1.12.3)
- deflate:より良い/より速いハフマン符号化#374
- deflate:履歴に割り当てる量を減らします。#375
- zstd:転送読み取りエラー#373
-
2021年4月27日(v1.12.2)
- zstd: Improve better/best compression #360 #364 #365
- zstd: Add helpers to compress/decompress zstd inside zip files #363
- deflate: Improve level 5+6 compression #367
- s2: Improve better/best compression #358 #359
- s2: Load after checking src limit on amd64. #362
- s2sx: Limit max executable size #368
-
Apr 14, 2021 (v1.12.1)
- snappy package removed. Upstream added as dependency.
- s2: Better compression in "best" mode #353
- s2sx: Add stdin input and detect pre-compressed from signature #352
- s2c/s2d: Add http as possible input #348
- s2c/s2d/s2sx: Always truncate when writing files #352
- zstd:WithLowerEncoderMem #346を使用する場合、メモリ使用量をさらに削減します
- s2:amd64アセンブリとプロファイラーの潜在的な問題を修正#349
v1.11.xへの変更を参照してください
-
2021年3月26日(v1.11.13)
-
2021年3月5日(v1.11.12)
-
2021年3月1日(v1.11.9)
- s2: Add ARM64 decompression assembly. Around 2x output speed. #324
- s2: Improve "better" speed and efficiency. #325
- s2: Fix binaries.
-
Feb 25, 2021 (v1.11.8)
- s2: Fixed occational out-of-bounds write on amd64. Upgrade recommended.
- s2: Add AMD64 assembly for better mode. 25-50% faster. #315
- s2: Less upfront decoder allocation. #322
- zstd: Faster "compression" of incompressible data. #314
- zip: Fix zip64 headers. #313
-
Jan 14, 2021 (v1.11.7)
- Use Bytes() interface to get bytes across packages. #309
- s2: Add 'best' compression option. #310
- s2: Add ReaderMaxBlockSize, changes
s2.NewReader
signature to include varargs. #311
- s2: Fix crash on small better buffers. #308
- s2: Clean up decoder. #312
-
Jan 7, 2021 (v1.11.6)
- zstd: Make decoder allocations smaller #306
- zstd: Free Decoder resources when Reset is called with a nil io.Reader #305
-
Dec 20, 2020 (v1.11.4)
- zstd: Add Best compression mode #304
- Add header decoder #299
- s2: Add uncompressed stream option #297
- Simplify/speed up small blocks with known max size. #300
- zstd: Always reset literal dict encoder #303
-
Nov 15, 2020 (v1.11.3)
- inflate: 10-15% faster decompression #293
- zstd: Tweak DecodeAll default allocation #295
-
Oct 11, 2020 (v1.11.2)
- s2:「より良い」ブロック圧縮で読み取られた範囲外を修正#291
-
2020年10月1日(v1.11.1)
- zstd:デフォルト構成でallLitEntropyをtrueに設定#286
-
2020年9月8日(v1.11.0)
v1.10.xへの変更を参照してください
v1.10.0より前の変更を参照してください
- Jan 20,2020 (v1.9.8) Optimize gzip/deflate with better size estimates and faster table generation. #207 by luyu6056, #206.
- Jan 11, 2020: S2 Encode/Decode will use provided buffer if capacity is big enough. #204
- Jan 5, 2020: (v1.9.7) Fix another zstd regression in v1.9.5 - v1.9.6 removed.
- Jan 4, 2020: (v1.9.6) Regression in v1.9.5 fixed causing corrupt zstd encodes in rare cases.
- Jan 4, 2020: Faster IO in s2c + s2d commandline tools compression/decompression. #192
- Dec 29, 2019: Removed v1.9.5 since fuzz tests showed a compatibility problem with the reference zstandard decoder.
- Dec 29, 2019: (v1.9.5) zstd: 10-20% faster block compression. #199
- Dec 29, 2019: zip package updated with latest Go features
- Dec 29, 2019: zstd: Single segment flag condintions tweaked. #197
- Dec 18, 2019: s2: Faster compression when ReadFrom is used. #198
- Dec 10, 2019: s2: Fix repeat length output when just above at 16MB limit.
- Dec 10, 2019: zstd: Add function to get decoder as io.ReadCloser. #191
- Dec 3, 2019: (v1.9.4) S2: limit max repeat length. #188
- Dec 3, 2019: Add WithNoEntropyCompression to zstd #187
- Dec 3, 2019: Reduce memory use for tests. Check for leaked goroutines.
- Nov 28, 2019 (v1.9.3) Less allocations in stateless deflate.
- Nov 28, 2019: 5-20% Faster huff0 decode. Impacts zstd as well. #184
- 2019年11月12日(v1.9.2)gzip/deflateのステートレス圧縮を追加しました。
- 2019年11月12日:大きな単一ブロックのzstd解凍を修正しました。#180
- 2019年11月11日:デフォルト のs2cブロックサイズを4MBに設定します。
- 2019年11月11日:膨張メモリの使用量を1KB削減します。
- 2019年11月10日:デフレートビットライターの割り当てが少なくなりました。
- 2019年11月10日:zstdデコーダーによって返される一貫性のないエラーを修正しました。
- 2019年10月28日(v1.9.1)ztsd:ブロックを圧縮するときのクラッシュを修正しました。#174
- 2019年10月24日(v1.9.0)zstd:まれなデータ破損を修正#173
- 2019年10月24日zstd:バッファ書き込み#171からhuff0を修正し、常にエラー#172を返します
- 2019年10月10日:大幅なデフレートの書き換え、より優れた圧縮で30〜40%高速化#105
v1.9.0より前の変更を参照してください
- Oct 10, 2019: (v1.8.6) zstd: Allow partial reads to get flushed data. #169
- Oct 3, 2019: Fix inconsistent results on broken zstd streams.
- Sep 25, 2019: Added
-rm
(remove source files) and -q
(no output except errors) to s2c
and s2d
commands
- Sep 16, 2019: (v1.8.4) Add
s2c
and s2d
commandline tools.
- Sep 10, 2019: (v1.8.3) Fix s2 decoder Skip.
- Sep 7, 2019: zstd: Added WithWindowSize, contributed by ianwilkes.
- Sep 5, 2019: (v1.8.2) Add WithZeroFrames which adds full zero payload block encoding option.
- Sep 5, 2019: Lazy initialization of zstandard predefined en/decoder tables.
- Aug 26, 2019: (v1.8.1) S2: 1-2% compression increase in "better" compression mode.
- Aug 26, 2019: zstd: Check maximum size of Huffman 1X compressed literals while decoding.
- Aug 24, 2019: (v1.8.0) Added S2 compression, a high performance replacement for Snappy.
- Aug 21, 2019: (v1.7.6) Fixed minor issues found by fuzzer. One could lead to zstd not decompressing.
- Aug 18, 2019: Add fuzzit continuous fuzzing.
- Aug 14, 2019: zstd: Skip incompressible data 2x faster. #147
- Aug 4, 2019 (v1.7.5): Better literal compression. #146
- Aug 4, 2019: Faster zstd compression. #143 #144
- Aug 4, 2019: Faster zstd decompression. #145 #143 #142
- July 15, 2019 (v1.7.4): Fix double EOF block in rare cases on zstd encoder.
- July 15, 2019 (v1.7.3): Minor speedup/compression increase in default zstd encoder.
- July 14, 2019: zstd decoder: Fix decompression error on multiple uses with mixed content.
- July 7, 2019 (v1.7.2): Snappy update, zstd decoder potential race fix.
- June 17, 2019: zstd decompression bugfix.
- June 17, 2019: fix 32 bit builds.
- June 17, 2019: Easier use in modules (less dependencies).
- June 9, 2019: New stronger "default" zstd compression mode. Matches zstd default compression ratio.
- June 5, 2019: 20-40% throughput in zstandard compression and better compression.
- June 5, 2019: deflate/gzip compression: Reduce memory usage of lower compression levels.
- June 2, 2019: Added zstandard compression!
- May 25, 2019: deflate/gzip: 10% faster bit writer, mostly visible in lower levels.
- Apr 22, 2019: zstd decompression added.
- Aug 1, 2018: Added huff0 README.
- Jul 8, 2018: Added Performance Update 2018 below.
- Jun 23, 2018: Merged Go 1.11 inflate optimizations. Go 1.9 is now required. Backwards compatible version tagged with v1.3.0.
- Apr 2, 2018: Added huff0 en/decoder. Experimental for now, API may change.
- Mar 4, 2018: Added FSE Entropy en/decoder. Experimental for now, API may change.
- Nov 3, 2017: Add compression Estimate function.
- May 28, 2017: Reduce allocations when resetting decoder.
- Apr 02, 2017: Change back to official crc32, since changes were merged in Go 1.7.
- Jan 14, 2017: Reduce stack pressure due to array copies. See Issue #18625.
- Oct 25, 2016: Level 2-4 have been rewritten and now offers significantly better performance than before.
- Oct 20, 2016: Port zlib changes from Go 1.7 to fix zlib writer issue. Please update.
- Oct 16, 2016: Go 1.7 changes merged. Apples to apples this package is a few percent faster, but has a significantly better balance between speed and compression per level.
- Mar 24, 2016: Always attempt Huffman encoding on level 4-7. This improves base 64 encoded data compression.
- Mar 24, 2016: Small speedup for level 1-3.
- Feb 19, 2016: Faster bit writer, level -2 is 15% faster, level 1 is 4% faster.
- Feb 19, 2016: Handle small payloads faster in level 1-3.
- Feb 19, 2016: Added faster level 2 + 3 compression modes.
- Feb 19, 2016: Rebalanced compression levels, so there is a more even progresssion in terms of compression. New default level is 5.
- Feb 14, 2016: Snappy: Merge upstream changes.
- Feb 14, 2016: Snappy: Fix aggressive skipping.
- Feb 14, 2016: Snappy: Update benchmark.
- Feb 13, 2016: Deflate: Fixed assembler problem that could lead to sub-optimal compression.
- Feb 12, 2016: Snappy: Added AMD64 SSE 4.2 optimizations to matching, which makes easy to compress material run faster. Typical speedup is around 25%.
- Feb 9, 2016: Added Snappy package fork. This version is 5-7% faster, much more on hard to compress content.
- Jan 30, 2016: Optimize level 1 to 3 by not considering static dictionary or storing uncompressed. ~4-5% speedup.
- Jan 16, 2016: Optimization on deflate level 1,2,3 compression.
- Jan 8 2016: Merge CL 18317: fix reading, writing of zip64 archives.
- Dec 8 2015: Make level 1 and -2 deterministic even if write size differs.
- Dec 8 2015: Split encoding functions, so hashing and matching can potentially be inlined. 1-3% faster on AMD64. 5% faster on other platforms.
- Dec 8 2015: Fixed rare one byte out-of bounds read. Please update!
- Nov 23 2015: Optimization on token writer. ~2-4% faster. Contributed by @dsnet.
- Nov 20 2015: Small optimization to bit writer on 64 bit systems.
- 2015年11月17日:基になるライターがエラーを返した場合の範囲外エラーを修正しました。#15を参照してください。
- 2015年11月12日:io.WriterToサポートをgzip/inflateに追加しました。
- 2015年11月11日:CL 16669を統合:アーカイブ/ zip:ファイルごとの(解凍)コンプレッサーのオーバーライドを有効にする
- 2015年10月15日:非圧縮データのスキップを追加しました。ランダムデータの速度が5倍以上になります。
使用量を減らす
パッケージは、標準ライブラリのドロップイン代替品です。それらを使用するには、インポートパスを置き換えるだけです。
古いインポート |
新規インポート |
ドキュメンテーション |
compress/gzip |
github.com/klauspost/compress/gzip |
gzip |
compress/zlib |
github.com/klauspost/compress/zlib |
zlib |
archive/zip |
github.com/klauspost/compress/zip |
ジップ |
compress/flate |
github.com/klauspost/compress/flate |
フラット |
また、大きなファイルでのマルチスレッド圧縮とこれらのパッケージで使用される最適化されたcrc32パッケージをサポートするgzipの代わりとなるpgzipにも興味があるかもしれません。
パッケージには標準ライブラリと同じものが含まれているため、そのためにgodocを使用できます:gzip、zip、 zlib、flate。
現在、解凍のスピードアップはわずかです(主にCRC32計算)。
ライターのメモリ使用量は通常1MBです。stdlibは同じ範囲にあります。同時に割り当てられるライターが多数あると予想される場合は、以下で説明するステートレス圧縮の使用を検討してください。
圧縮パフォーマンスについては、このスプレッドシートを参照してください。
ステートレス圧縮
このパッケージは、gzip/deflateの特別なオプションとしてステートレス圧縮を提供します。圧縮は行いますが、書き込み呼び出しの間に状態を維持することはありません。
これは、書き込み呼び出しの間にメモリが保持されないことを意味しますが、圧縮と速度は最適ではありません。
これは、何千ものコンプレッサーを同時に実行することが予想されるが、アクティビティがほとんどない場合にのみ関係します。これは、個々のリクエストを処理する通常のWebサーバーを対象としていません。
このため、実際の書き込み呼び出しのサイズは出力サイズに影響します。
gzipで、level
-3
/
gzip.StatelessCompression
を指定して有効にします。
直接デフレートを使用する場合は、NewStatelessWriterとStatelessDeflateを使用できます。ドキュメントを参照してください
bufio.Writer
もちろん、書き込みサイズを制御するために使用できます。たとえば、4KBのバッファを使用するには:
// replace 'ioutil.Discard' with your output.
gzw, err := gzip.NewWriterLevel(ioutil.Discard, gzip.StatelessCompression)
if err != nil {
return err
}
defer gzw.Close()
w := bufio.NewWriterSize(gzw, 4096)
defer w.Flush()
// Write to 'w'
これは、ライターがアイドル状態のときにメモリ内で最大4KBしか使用しません。
ほとんどの場合、圧縮は最速の圧縮レベルよりも悪く、書き込みごとに(少しの)メモリが割り当てられます。
パフォーマンスアップデート2018
このパッケージの速度を標準ライブラリと比較して検討してからしばらく経ちましたので、テストをやり直して、現在の状態に基づいて全体的な推奨事項を提示したいと思いました。すべてのベンチマークは、デスクトップIntel(R)Core(TM)i7-2600 [email protected]でGo1.10を使用して実行されました。最後にテストを実行してから、RAMが増えました。つまり、大きなファイルを使用したテストはSSDによって制限されなくなりました。
生の結果は、更新されたスプレッドシートにあります。cgoの変更とアップストリームの更新により、cgoバージョンのgzipをコンパイルできませんでした。代わりに、zstdcgoの実装を含めました。cgo gzipが再び機能するようになった場合、シートの結果を置き換える可能性があります。
注意すべき列は次のとおりです。MB/s-スループット。削減-元のデータのパーセントでのデータサイズの削減。同じレベルの標準ライブラリと比較したRelSpeedの相対速度。小さい-stdlibと比較して圧縮出力が何パーセント小さいか。負の値は、出力が大きかったことを意味します。損失とは、入力のパーセンテージの差としての圧縮の損失(またはゲイン)を意味します。
(
gzstd
標準ライブラリgzip)と
gzkp
(このパッケージgzip)は1つのCPUコアのみを使用します。
pgzip
、
bgzf
4つのコアすべてを使用します。
zstd
1つのコアを使用し、獣です(ただし、まだGoではありません)。
全体的な違い。
同様の圧縮レベルで比較すると、標準ライブラリに比べて約5〜10%の速度の利点があるようです。
表示される最大の違いは、圧縮レベルのバランスを取り直した結果です。私はライブラリによって、標準ライブラリよりも圧縮レベル間のスムーズな移行を実現したいと考えていました。
このパッケージは、よりスムーズな移行を提供しようとします。「1」は多くのショートカットを使用し、「5」は妥当なトレードオフであり、「9」は「最高の圧縮を提供する」であり、その間の値は間に合理的な何か。標準ライブラリにはレベル1〜4で大きな違いがありますが、レベル5〜9には大きなメリットはなく、多くの場合、達成された圧縮によって正当化できるよりもはるかに多くの時間を費やしています。
各タブの左上のフィールドに、スプレッドシートのすべてのテストデータへのリンクがあります。
Webコンテンツ
このテストセットは、Webサーバーでの一般的な使用法をエミュレートすることを目的としています。テストセットは53kファイルの4GBデータであり、(ほとんど)HTML、JS、CSSの混合物です。
レベル1と9はほぼ同じコードであるため、非常に近いです。しかし、その間のレベルを見ると、違いはかなり大きいです。
レベル6を見ると、このパッケージは88%高速ですが、約6%多くのデータを出力します。Webサーバーの場合、これは88%多いデータを提供できることを意味しますが、6%多い帯域幅を支払う必要があります。あなたはあなたのケースにとって何が最も高価であるかについてあなた自身の結論を引き出すことができます。
オブジェクトファイル
このテストは、サーバーに保存されている一般的なデータファイルを対象としています。この場合、これはGoでプリコンパイルされたオブジェクトのコレクションです。それらは非常に圧縮可能です。
画像はWebコンテンツに似ていますが、非常に圧縮可能であるため、わずかな違いがあります。レベル2〜3は優れた速度を提供しますが、かなりの圧縮を犠牲にしています。
標準ライブラリは、レベル3と4では最適ではないようです。このパッケージのレベル6と7よりも、圧縮と速度の両方が劣っています。
高圧縮性ファイル
これは非常に冗長性の高いJSONファイルです。削減はレベル1の95%から始まります。したがって、実際には、非常に冗長なデータストリームなどを扱っています。
ここでは専門的なコンテンツを扱っていることがはっきりとわかりますので、結果は非常に散らばっています。このパッケージは、レベル1〜4ではあまりうまく機能しませんが、レベル5とレベル7および8で大幅に向上し、達成された圧縮に優れた速度を提供します。
So if you know you content is extremely compressible you might want to go slightly higher than the defaults. The standard library has a huge gap between levels 3 and 4 in terms of speed (2.75x slowdown), so it offers little "middle ground".
Medium-High Compressible
This is a pretty common test corpus: enwik9. It contains the first 10^9 bytes of the English Wikipedia dump on Mar. 3, 2006. This is a very good test of typical text based compression and more data heavy streams.
We see a similar picture here as in "Web Content". On equal levels some compression is sacrificed for more speed. Level 5 seems to be the best trade-off between speed and size, beating stdlib level 3 in both.
Medium Compressible
2つのテストセットを組み合わせます。1つは10GBのファイルセットで、もう1つはVMディスクイメージ(〜8GB)です。どちらも異なるデータ型を含み、典型的なバックアップシナリオを表しています。
最も注目すべき点は、標準ライブラリが、圧縮率を大幅に向上させることなく、レベル5〜6付近の非常に低い圧縮速度にどれだけ速く低下するかです。このタイプのデータはかなり一般的であるため、これは適切な動作ではないようです。
非圧縮性コンテンツ
これは主に、アルゴリズムが非圧縮性入力の検出にどれだけ優れているかをテストするものです。標準ライブラリは、レベル1の非常に控えめな設定でのみこの機能を提供します。明らかに、アルゴリズムが圧縮できない入力を圧縮しようとする理由はありません。唯一の欠点は、誤検出時に圧縮可能なデータをスキップする可能性があることです。
ハフマンのみの圧縮
この圧縮ライブラリは、という名前の特別な圧縮レベルを追加します
HuffmanOnly
。これにより、ほぼ線形時間の圧縮が可能になります。これは、前のデータの照合を完全に無効にし、各文字を表すビット数を減らすことによって行われます。
これは、テキストで「e」や「」(スペース)などの頻繁に使用される文字は、表現に最も少ないビットを使用し、「¤」などのまれな文字は、表現にさらに多くのビットを使用することを意味します。詳細については、ウィキペディアまたはこの素敵なビデオを参照してください。
このタイプの圧縮は分散がはるかに少ないため、圧縮速度は入力データの影響をほとんど受けず、通常、シングルコアの場合は180MB/秒を超えます。
欠点は、圧縮率が通常、最速の従来の圧縮よりもかなり悪いことです。圧縮率が8:1(12.5%)を超えることはありません。
線形時間圧縮は、「何もないよりも優れた」モードとして使用できます。このモードでは、一部のコンテンツでエンコーダーの速度が低下するリスクを冒すことはできません。比較のために、「Twain」テキストのサイズは233460バイト(レベル1に対して+ 29%)であり、エンコード速度は144MB /秒(4.5xレベル1)です。したがって、この場合、30%のサイズ増加を4倍のスピードアップと交換します。
詳細については、高速線形時間圧縮に関する私のブログ投稿を参照してください。
これはGo1.7で「ハフマンのみ」モードとして実装されていますが、gzipでは公開されていません。
その他のパッケージ
良質で純粋なGo(cgoラッパーや自動変換されたコードなし)の他のパッケージは次のとおりです。
ライセンス
このコードは、元のGoコードと同じ条件でライセンスされます。LICENSEファイルを参照してください。