6

私はすでにメモリ内圧縮をグーグルで検索しており、この機能を提供するかなりの数のライブラリを見つけました。zlib は広く使われているようですが、かなり古いものでもあるようです。ここで、より新しく、より優れた代替手段があるかどうかを尋ねています。

メモリ内で圧縮したいデータは、サイズが数メガバイト (2 ～ 16 MB) のメモリプールであり、これらの各ブロックには、2 つの異なる構造体のデータとポインターの配列が含まれています。ブロック内では、構造体と配列に特定の順序はありません。それらは、アプリケーションがそのような要素を作成する必要があるときに、次々に割り当てられます。

これに対してどの圧縮ライブラリを提案しますか? 圧縮と解凍のパフォーマンス (両方) は、圧縮品質よりも重要です。

また、圧縮の理由から、圧縮される各データブロックに1種類のデータのみが含まれるように、2つの異なる構造体と配列に個別のプールを用意する方がよいでしょうか?

インメモリ圧縮を使用するのはこれが初めてであり、私の質問が一般的すぎて適切な回答が得られないことはわかっていますが、すべてのヒントを歓迎します!

どうも！

4

6 に答える 6

10

zlibは良いです。実績があり、パフォーマンスが高く、多くの人に理解されています。これは、あなたが説明しているような新しいシステムでデフォルトで使用するものです。その時代は、その最大の資産の1つと見なされるべきです。

于 2010-01-02T17:58:59.280 に答える
3

zlibよりも新しいものについては、libbzip2は一見の価値があるかもしれません。互換性のために、zlibと同様のインターフェースを提供します。多くの場合、圧縮率は高くなりますが、パフォーマンスが低下します。

zlibよりも高速なもの（ただし、圧縮もされません..）には、LZOがあります。

于 2010-01-02T18:05:23.777 に答える
1

仮想メモリマネージャーを備えた最新のオペレーティングシステムでこれを行うことは意味がありません。何の役にも立たないバイトのブロブを作成し、正当な理由もなく仮想メモリ アドレス空間の領域を占有します。メモリ マネージャーは、BLOB によって占有されているページがアクセスされていないことに気付き、ページング ファイルにスワップ アウトします。

さらに、ポインターが含まれている場合は、データを変換する必要があります。正確に同じ仮想メモリ アドレスでデータを圧縮解除できる可能性があり、ポインタがまだ有効である可能性はゼロに非常に近いです。結局のところ、仮想メモリ領域を解放するためにこれを行ったので、以前にデータによって使用されていた穴が別のものによって占有されます。この変換はおそらく簡単ではなく、追加のメモリを大量に必要とします。

OOM を回避するためにこれを行っている場合は、メモリ マップト ファイルに対するオペレーティング システムのサポートを確認し、64 ビット コードへの切り替えを検討してください。

于 2010-01-02T18:50:49.210 に答える
1

圧縮/解凍速度が重要な場合は、LZO を検討する必要があります。

http://www.oberhumer.com/opensource/lzo/

zlib と比較すると、コードが小さくなり、使いやすくなります。

于 2010-01-02T22:44:20.720 に答える
0

zlibよりも新しい/優れたものは何も知りません...zlibは、その古さにもかかわらず、正常に動作します。zlibのdeflateInit（）には、圧縮速度と圧縮サイズのトレードオフを可能にする引数があるため、それを試して、アプリケーションに最適な設定を見つけることができます。

おそらく、zlib C APIを呼び出すC++ラッパーAPIがあります。「よりきれいな」ものが必要な場合、またはない場合は、独自のAPIを作成するのは簡単です。

于 2010-01-02T17:59:45.737 に答える
0

圧縮の場合、データは非常に重要です。メモリ内の任意のバイナリ データを圧縮することは完全に時間の無駄であり、パフォーマンスが大幅に低下し、メモリ使用量が増加する可能性があります。

本当にもっと多くのメモリが必要な場合は、VirtualAlloc または sbrk を使用して自分でメモリを制御することを検討する必要があります。この方法で、2 ～ 4 GB だけでなく、すべての物理メモリをアドレス指定できます。

于 2010-01-03T05:11:23.517 に答える