C＃のハッシュテーブルと辞書の実用的なサイズ制限

C＃4ディクショナリまたはHashtableに含めることができるアイテムの数と、これらの構造に合理的に含めることができる合計バイト数の実際的な制限は何ですか。多数のオブジェクトを使用して、これらの構造がいつ問題を起こし始めるかを知りたいと思います。

コンテキストでは、大量のメモリを備えた64ビットシステムを使用します。また、何らかのフォームまたは「キー」を使用してオブジェクトを見つける必要があります。パフォーマンスの要求を考えると、これらのオブジェクトはメモリに常駐する必要があり、多くは存続します。

サードパーティまたはオープンソースのライブラリを使用しないようにする必要がありますが、他のアプローチ/パターンを自由に提案してください。仕様上の理由から、ネイティブC＃（またはC ++ \ CLI）を使用してこれをビルドできる必要があります。

指摘すべきことの1つは、ディクショナリがオブジェクト自体（メモリフットプリントが大きい可能性がある）を保持するのではなく、オブジェクトへの参照のみを保持するため、オブジェクトが複雑な場合、ディクショナリのサイズには影響しないことです。

メモリ内のディクショナリに数千のアイテムをまとめて収集しましたが、問題はディクショナリのサイズではなく、メモリ内のオブジェクト自体のサイズです。これらの場合、辞書自体は、関与するメモリのごく一部でした。

大規模な辞書の場合に考慮すべきことの1つは、辞書の容量を手動で構成および管理することです。通常の状況では、.Netがこの罰金を管理します（現在の実装では、スペースが不足すると、辞書の現在のサイズの少なくとも2倍の素数にサイズ変更されます）。ただし、大規模なディクショナリを作成することがわかっている場合、または.Netでディクショナリを推測してサイズを変更するのではなくディクショナリを拡張する場合（比較的コストがかかる）、おそらく自分でこれを行うことをお勧めします（最初のサイズとおそらく後のサイズ変更の管理）。これは、辞書の容量がどうあるべきかについての合理的な発見的アイデアを持っている場合、辞書の容量を管理することで実行できます。マイクロソフトはこれを推奨しますMSDNは、Dictionaryオブジェクトに関する備考で述べています。ただし、このアプローチの実際の価値については議論がありそうですが、そのテストがどれほど厳密であるか、また辞書が非常に急速にサイズ変更されるときに.Netプラットフォームが実施する他の最適化があるかどうかはわかりません。

これは、オブジェクトとメモリサイズに関するStack Overflowの便利な質問です。

実際の制限は、ソフトウェアが実行されているマシン、およびこれらのデータ構造内に実際に含める予定のオブジェクトの数に関連する場合があります。Odedが述べたように、int.MaxValueは多数ですが、20億のアイテムは実際的な制限に相当しますか？多くのアイテムをメモリに保存することは、あまり実用的ではないでしょう。

ドキュメントにはデータが物理的に保存されている場所と制限が指定されていないため、予想される最大予想サイズで実験を行い、ストレージ割り当ての前後にシステムメモリを記録することをお勧めします。

最近、githubプロジェクトhash-table-shootoutを更新しました（こちら：https : //github.com/jimbelton/hash-table-shootout）。標準のgcc順序付けられていないマップには、40Mのオブジェクトを保存するための約1.8Gバイトのオーバーヘッドがあります。私にはこれは非常に恐ろしいように思えますが、メモリに関して最高のパフォーマンスを発揮するGoogleのsparse_hash_mapでさえ600 Mバイトかかり、それを使用するとパフォーマンスが低下します。含まれるアルゴリズムのうち、速度が必要な場合は、Glib GHashTableが最速であり、優れたメモリパフォーマンス（約1.3ギガバイトのオーバーヘッド）があります。ベンチマーク結果はここに投稿されます：https : //jimbelton.wordpress.com/2015/07/01/hash-table-shootout-on-github/