容量を持つオブジェクトを使用する場合、コレクションに使用するときの効率を保証するために使用できるガイドラインは何ですか？また、.NETフレームワークがこれらの容量のいくつかを低く設定しているようです。例えば、私はStringBuilderの初期容量が16であると思います。これは、16個の文字列がStringBuilderに挿入された後、StringBuilderオブジェクトが再割り当てされ、サイズが倍増することを意味しますか？ StringBuilderでコレクションオブジェクトの初期容量を決定する最善の方法は何ですか？
、それは弦の数が、文字の数ではありません。一般に;あなたは長さを予測することができれば、先に行くと、それを教えて - それは倍増使用していますので、あなたはほとんどの場合など
使用Addが突出する必要がある場合は、巨大オーバーヘッドは時折再割り当てではありません、違い自明であり、マイクロ最適化である。サイズを教えていない最大の問題は、コレクションに「トリム」メソッドがないかぎり、本当に必要なサイズが2倍近く（不運な場合）です。
コレクションまたはStringBuilderがどのくらい大きくなるか分かっている場合は、それをコンストラクタの容量として渡すことをお勧めします。そうすれば、1つの割り当てだけが行われます。正確な数字がわからない場合は、近似でさえ役立つことがあります。
私が今まで明示的に私がコレクションに表示される項目の正確な数を知っていると私はT >配列またはリスト<を使用していますコレクション
興味深いことに、＃1については、COMインターフェイスからBCLコレクションクラスに返されたデータをコピーするときにほとんど常に行われます。だから私は、あなたは私がinteropシナリオでこれを行うことしかできないと言うことができると思います。
辞書を増やすことはそれほどコストがかかる操作なので、辞書に特に役立ちます。 –
しかし、辞書の初期容量を設定する際の問題は、負荷率を考慮する必要があることです。 –
StringBuilderと言えば、私は最悪の場合のサイズを使用したいと思います。 StringBuilderには、断片化されたヒープに割り当てるのが難しい連続したメモリブロックが必要です。
私は他のコレクションの見積もりに行くと思います。
StringBuilderは特別ではありません。すべてのオブジェクトは連続したメモリを必要とします。あなたのヒープが断片化していて、StringBuilderを割り当てることができなかった場合は、大きな文字列でなければ、もっと大きな問題があると思います。 –
'すべてのオブジェクトに連続したメモリが必要です。 'あなたは真剣にいくつかのMBのようなオブジェクトを持つことが一般的なケースであることを暗示していますか？ 8Mバイトの大きな文字列ビルダを割り当てて9MBのデータを収めようとすると、失敗する可能性が高くなりますが、10mbのstringbuilderは最初はうまく割り当てられます。 – arul
"いくつかのMBのようなオブジェクトを持つのが一般的なケースであることを真剣に暗示していますか？なぜ、はい、私です。人々は、数千万のアイテムを含むコレクションを定期的に使用します。 10Mのリファレンス= 40MB（64ビットシステムでは80MB）。 –
おおよそおおよその場所を残してください。 –