Josh Smith のブログ エントリを読んでいて、「マネージ ヒープの断片化を減らす」ためにキャッシュ メカニズムを使用していました。彼のキャッシングは、実行速度がわずかに遅くなりますが、作成される存続期間の短いオブジェクトの数を減らします。
C# のようなマネージ言語でのマネージ ヒープの断片化はどの程度の問題ですか? 問題があるかどうかをどのように診断できますか? 通常、どのような状況でそれに対処する必要がありますか?
質問する
1075 次
4 に答える
7
いつ
速すぎない。一般に、存続期間の短いオブジェクトを持つことは非常に安価です。キャッシュが利益を上げるためには、（非常に）多くの候補者が必要であり、彼らは次世代に引き継ぐのに十分な長さである必要があります.
問題があるかどうかをどのように診断できますか?
プロファイラー付き。記事の著者がそれをしたかどうかはわかりません。
C# のようなマネージ言語でのマネージ ヒープの断片化はどの程度の問題ですか?
私の知る限り、それはまれです。.NET には圧縮ガベージ コレクターがあり、ほとんどの形式の断片化を防ぎます。ラージ オブジェクト ヒープに問題が発生することがあります。
編集：
この記事の下にあるコメントを読むと、誰かがそれを測定した結果、毎回新しい eventargs を作成するよりもキャッシュの方がはるかに遅いことがわかります。
結論:最適化を開始する前に測定してください。これは良い考え/例ではありませんでした。
于 2010-04-08T14:57:37.763 に答える
4
1 秒あたり 10,000 個以上の小さな存続期間の短いオブジェクトを処理している場合を除き、適切な量の RAM を備えた最新のコンピューターではまったく問題になりません。
したがって、最初にすべての合理的なシナリオでコードを実行する必要があります。十分に高速であれば、心配する必要はありません。
速度に満足できない場合は、コードが「チョーク」することがあります。または単に興味がある場合は、さまざまな .NET メモリ統計を監視できます ( http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx ) パフォーマンス モニター アプリ (Windows の一部として提供されます)。具体的には、% Time in GC に関心があります。
redgate ANTS プロファイラーもこれらの統計を監視します。
于 2010-04-08T14:57:03.127 に答える
1
通常、マネージド ヒープの断片化は、オブジェクトの固定が原因です。マネージ コードがオブジェクト ポインターをネイティブ コードに渡すと、オブジェクトが固定され、参照がネイティブ コードに渡されるため、オブジェクトを移動できません。これは、多くの I/O アクティビティがある場合に非常に一般的です。上記のように、通常は LOH でのみ発生します。
Gen0 ヒープでの断片化の例を次に示します。
于 2010-04-08T16:54:26.200 に答える
0
ここで与えられた他の回答とは異なり、私は次のように述べています。はい、断片化に注意する必要があります! これはマネージド ヒープだけでなく、(少なくとも) すべてのアプリ処理に適用されます。
- 多くの「大きな」リソース
- 重い割り当てパターン。
LOB は圧縮されないため、オブジェクトのサイズと数が特定の値 (使用可能な全体の最大ヒープサイズに関連する) を超えるとすぐに、時間の経過とともにフラグメント化される可能性が高くなります。その場合、唯一の安全な方法は、それらのオブジェクトへの参照を即座に保持する数を制限することです。キャッシュ (プール) は、プールされたオブジェクトを再利用できる場合にのみ役立ちます。これらのリソースがさまざまな長さ fe の配列で構成されている場合、簡単に再利用できないことがあります。したがって、プーリングはここではあまり役に立たないかもしれません。
それを検出する方法は？LOB ヒープに大きな負荷がかかるとき。それを調べる方法は？.NET パフォーマンス カウンター「Collection Count Gen 0...2」を同時に使用します。LOB から割り当てられる大きなオブジェクトが多すぎると、すべてのカウンターが同じように展開されます。つまり、基本的にすべてのコレクションは高価なジェネレーション 2 コレクションです。その場合、何かをする必要があります。
小さいオブジェクトに関しては、Gen 0 コレクションのすべての作業を GC に任せ、心配する必要はありません。
于 2011-01-16T16:22:05.500 に答える