1

私は、24 時間にわたって新しいアイテムをセットに追加し続けるサーバーを持っています。要素は 24 期間にわたって削除されず、新しい要素が挿入され続けます。

その後、期間の終わりにセットがクリアされ、新しい要素がさらに 24 時間追加され始めます。

ここで、メモリを再利用し、断片化に役立つ可能性があるため、高速プールアロケーターが役立つと思いますか?

セットは約 100 万要素にまで増加します。各要素は約 1k です。

4

1 に答える 1

2

可能性は非常に低いですが、もちろん、プログラムで自由にテストできます。

そのサイズと割り当てパターン (more! more! more! + grow! grow! grow!) のコレクションには、ベクトルの配列を使用する必要があります。連続したブロックに保持するだけでreserve()、それらが作成されたときに、スペースと帯域幅トラバーシング リストを再割り当て/サイズ変更したり、無駄にしたりする必要はありません。vector は、コレクションが大きい場合のメモリ レイアウトに最適です。1 つの大きなベクトル (サイズ変更に時間がかかる) ではなく、それぞれがチャンクを表す複数のベクトル (理想的なチャンク サイズはプラットフォームによって異なる場合があります。私はそれぞれ 5MB から始めて、そこから測定します)。従うと、メモリのサイズを変更したり再利用したりする必要がないことがわかります。次のオブジェクトのために数分ごとに割り当てを作成するだけNです。高頻度/高速のオブジェクト割り当てと再作成は必要ありません。

プール アロケータに関することは、不連続な割り当てを持つ多くのオブジェクト、大量の割り当てのリストのような大量の挿入と削除が必要であることを示唆しています。これはいくつかの理由で悪いことです。このサイズで連続した割り当てを最適化する実装を作成したい場合は、ベクターアプローチを使用したブロックを目指してください。割り当てとルックアップはどちらも最小限に近くなります。その時点で、割り当て時間は (他の作業に比べて) 小さいはずです。そうすれば、割り当てパターンについて異常なことや驚くべきことも何もなくなります。ただし、高速プール アロケーターは、このコレクションをリストとして扱うことを推奨しています。これは、この問題に対してひどいパフォーマンスをもたらします。

そのブロック + ベクトル アプローチを実装すると、(その時点で) より良いパフォーマンス比較は、boost の pool_allocator と std::allocator を比較することになります。もちろん、3 つすべてをテストすることもできますが、正しく実装すれば、ベクトルのブロック アプローチによってメモリの断片化が大幅に削減される可能性があります。参考：

パフォーマンスを重視する場合は、std::list などのコンテナーを扱う場合は fast_pool_allocator を使用し、std::vector などのコンテナーを扱う場合は pool_allocator を使用してください。

于 2013-08-02T06:00:59.653 に答える