.netのトライ実装を探しています。
これをメモリ内オブジェクトプールのインデックス構造として使用することを計画しています。スレッドセーフである必要はありませんが（1つのスレッドのみが更新するため）、少なくとも2,000万のアイテムを適切に、一定のパフォーマンスで処理できる必要があります。
ネットで見つけたのはサンプルコードかおもちゃのプロジェクトのようです。だから、私は本当に生産品質の実装を探しています。利用可能な場合は、商用ライブラリもOKです。
PS：私が見たハッシュテーブルの実装はメモリを使いすぎており、配列に基づいているためメモリの断片化を引き起こす傾向があるため、試行を選択しました。O（1）ルックアップ特性と多数のアイテムの良性メモリ使用特性を備えたこのようなコンテナも問題ありません。
ありがとうございました、
私の個人的な意見では、.Net 自身のメモリ管理を再考しようとすることは、私が推奨する方法ではありません。ネイティブ シナリオで可能なレベルのメモリ割り当てを制御することはできませんが、その必要もないはずです。私が最初に C++ から移行したとき (自分のヒープを定期的に操作し、メモリ ローカリゼーション ルーチンなどを記述していた)、これを実行したいという願望に取りつかれていましたが、すぐに、その必要がないことも、できないことも明らかになりました。私。
たとえば、MyPooledObjectトライの一番下に の配列を持つことができますが、それが参照型の場合は、それぞれの実際のメモリが別の場所にある参照の配列を取得するだけです。 t コントロール (独自のホストをランタイムに適合させない限り)。
代わりに値型を使用することになりますが、カスタム値型は不変である必要があるため、これらはプールされたシナリオでの使用には適していません (正当化することなく安全に言うことができます - Google の「不変」と「構造体」ターゲット サイトだけです)。 :stackoverflow.com で詳細を確認できます) したがって、再利用可能なオブジェクトとして扱うのは適切ではありません。
それぞれがハッシュ可能なキーで認識できる .Net 内のオブジェクトのインデックス付きコレクションが必要な場合は、ディクショナリを使用します。
オブジェクトが多すぎてメモリに収まらない場合は、次のいずれかを行います。
1) メモリを増やす
2) データベースを使用し、そのローカル セグメントをキャッシュする
または両方: AppFabric とそのキャッシュ機能を検討することもできます。そうすれば、何百万ものオブジェクトのメモリ内キャッシュを実行する専用のマシンのファームを構築できます。ハードウェアのコストは、.Net 用の独自のメモリ管理ソリューションを開発するコストよりもおそらく低くなります :)