次の記事では、ほとんどのサーバーが仮想化されているため、ほとんどのメモリがディスクにページングされることを考慮した代替ヒープ構造について説明します。
http://queue.acm.org/detail.cfm?id=1814327
親子関係が同じ仮想メモリ ページ内で維持されるように、.NET 開発者は B ヒープ データ構造を実装できますか (または実装する必要がありますか)? これはどのように、またはどこで実装されますか?
明確化
言い換えれば、このタイプのデータ構造は .NET 内でプリミティブ タイプとして必要ですか? 確かに、CLR でネイティブに実装するか、ap/invoke で実装する必要があります。
サーバー管理者が仮想マシン内に .NET アプリを展開する場合、このバイナリ ヒープの最適化は理にかなっていますか? もしそうなら、それはいつ意味がありますか？(オブジェクトの数など)
少なくともある程度まで、BCLコレクションはページングの懸念を考慮に入れているようです。また、CPUキャッシュの懸念も考慮に入れています（メモリの局所性は、さまざまな方法で両方に影響を与える可能性があるため、いくつかの点で重複しています）。
それを考慮してくださいQueue<T>内部ストレージに配列を使用します。純粋にランダムアクセスの用語では（つまり、ページングやCPUキャッシュのフラッシュにコストがかからない場合）、これは適切な選択ではありません。キューは、ほとんどの場合、ある時点でのみ追加され、別の時点で削除されるため、単一リンクリストとしての内部実装は、ほぼすべての方法で勝ちます（さらに言えば、キューの反復に関しては、これもサポートされます）。 -リンクリストは、この点で、純粋なランダムアクセスの状況で配列よりもはるかに悪くなることはありません）。配列ベースの実装が単一リンクリストよりも優れているのは、ページングとCPUキャッシュを考慮した場合です。そのMSは、純粋なランダムアクセスの状況ではより悪いが、ページングが重要である実際のケースではより良いソリューションを求めたため、ページングの影響に注意を払っています。
もちろん、それは明白ではありません-そしてそうであるべきではありません。外部からは、キューのように機能するものが必要です。内部を効率的にすることは別の関心事です。
これらの懸念は他の方法でも満たされます。たとえば、GCの動作方法では、移動するオブジェクトによって断片化が少なくなるだけでなく、ページフォールトも少なくなるため、必要なページングの量が最小限に抑えられます。他のコレクションも、最も直接的な解決策が示唆するよりもページングの頻度を少なくする方法で実装されます。
それは私が見たものから私に際立っているほんの少しのことです。そのような懸念は、.NETチームの他の多くの場所でも考慮されていると思います。他のフレームワークと同様に。Cliff ClickがJavaロックフリーハッシュテーブル（C＃実装のチェックを本当に終えています）に関して繰り返し言及している1つの大きなパフォーマンス上の懸念は、ロックフリー並行性（演習の要点）の問題とは別に、キャッシュラインであると考えてください。 ; そして、それは彼が却下しないもう1つのパフォーマンス上の懸念でもあります！
また、ほとんどのコレクションのほとんどの用途は、とにかく1ページに収まると考えてください。
独自のコレクションを実装している場合、または標準のコレクションを特に頻繁に使用している場合、これらは考慮する必要があることです（「いや、問題ではない」で十分な場合もあれば、そうでない場合もあります）が、そうではありません。つまり、BCLから得られるものに関してはまだ考えられていないということです。
特に特殊なシナリオとアルゴリズムがある場合は、そのような最適化の恩恵を受ける可能性があります。
しかし、一般的に言えば、CLRフレームワークのコア部分を（CLRの上に、つまりマネージコードで）再実装する場合、CLRチームよりも効率的に実行できる可能性は非常に低くなります。したがって、現在の実装の概要をすでに把握していて、メモリ内のデータの局所性に関連する問題を明確に特定していない限り、これはお勧めしません。それでも、アルゴリズムを微調整してCLRメモリ管理スキームをより適切に機能させ、それをバイパスまたは回避しようとすることで、より多くの利益を得ることができます。