The Apache Modules Bookを読んで、パート 3.4.3 でこの主張に出くわしました。
「第 2 の利点は、プールの割り当てがほとんどのプラットフォームで malloc よりも高速であることです!」
未解決の質問だと思いますが、まあ、なぜですか?
1719 次
2 に答える
6
局所性に関する Lars の指摘に加えて、プールの割り当ては単に .NET とは異なる速度/柔軟性のトレードオフですmalloc。
malloc割り当てられた各ブロックを追跡し、ブロックを個別に解放し、空きブロックの断片化と合体を処理し、いくつかの空きブロックのどれから割り当てるかを選択するための戦略を持たなければなりません。
これは汎用アロケーターに必要ですが、プールは、呼び出し元がこの動作の一部を静的に決定するようにすることで、この複雑さ (および関連するスペースと実行時のオーバーヘッド) をすべて回避します。
Apache の例では、プール全体の割り当て解除のみが許可されているようです (アリーナ アロケーターのようなものです)。これは、個々の割り当てレコード、それらの有効期間、および断片化されたフリー ストアを追跡する必要がないことを意味します。1 つ (または複数) の大きなメモリ チャンクを追跡し、次の未使用領域へのポインタを更新するだけで済みます。これらの大きなチャンクが を使用して割り当てられた場合でも、このコストは通常、多くのプール割り当てmallocで償却されることに注意してください。
他のプール タイプは、同じサイズ (またはタイプ) のオブジェクトに制限される場合があります。これにより、さらに単純化されます。LIFO フリーリストをゼロに近いコストで維持することもでき、レコードごとの割り当て解除が可能になります。
于 2012-08-15T11:47:06.893 に答える
4
プール割り当て戦略は、2 つの方法でパフォーマンスを向上させることができます。データ構造のトラバーサルがデータの割り当て順序と一致するアプリケーションでは、プーリング戦略により、より規則的なストライドが明らかになる可能性があります。
たとえば、レコードのリンク リストを検索する場合を考えてみましょう。各レコードは、キー フィールド、データ フィールド、およびリスト内の次のレコードを指す次のフィールドで構成されます。キーと次のフィールドは、一致が見つかるまで連続してアクセスされます。データフィールドがアクセスされるのはその時だけです。各レコードに格納されているデータ自体がヒープ オブジェクトであり、さらに悪いことに、データのサイズがレコードごとに異なる場合、ワーキング セットの空間的局所性にさまざまな望ましくない影響が生じます。つまり、データがメモリから不必要にフェッチされ、貴重な帯域幅が消費されます。
また、キー フィールドと次のフィールドの間に可変長データが介在するため、レコード内および連続するレコード間のストライドは不規則に見えます。したがって、さまざまなオブジェクト タイプを分離することで、空間的局所性が向上し、同時に全体的なパフォーマンスも向上します。
さらに、プールの割り当てによってより規則的なストライドが発生する可能性があるため、単純なプリフェッチ戦略で将来の参照を予測し、メモリ アクセスのレイテンシを短縮できます。
于 2012-08-15T11:34:19.120 に答える