ガベージコレクターのパフォーマンスを向上させるために、どのような最適化パターンを使用できますか？
私が尋ねる理由は、CompactFrameworkを使用して多くの組み込みソフトウェアを実行しているからです。低速のデバイスでは、ガベージコレクションが問題になる可能性があるため、ガベージコレクターが起動する回数を減らしたいのですが、発生した場合は、より早く終了するようにします。また、ガベージコレクターに対してではなく、ガベージコレクターを使用すると、.NETまたはJavaアプリケーション、特にヘビーデューティーWebアプリケーションの改善に役立つ可能性があることもわかります。
ここに私の考えのいくつかがありますが、私はベンチマークをしていません。
重要なのは、CFGCが割り当てに対してどのように機能するかを理解することです。これは、GCをトリガーするもの、および収集後に圧縮やピッチングを引き起こすものに関する特定のアルゴリズムを備えた、単純なマークアンドスイープの非世代型GCです。GCを制御するためにアプリレベルでできることはほとんどありません（使用できる唯一の方法はCollectであり、とにかく圧縮を強制できないため、その使用はかなり制限されています）。
オブジェクトの再利用は良いスタートですが、収集操作ではすべてのルートをたどる必要があるため、オブジェクトの数を少なく保つことはおそらく最良のツールの1つです。その散歩を短く保つことは良い考えです。圧縮があなたを殺しているなら、セグメントの断片化を防ぐことは助けになります。64kを超えるオブジェクトは、独自のセグメントを取得し、小さいオブジェクトとは異なる方法で処理されるため、この点で役立ちます。
CF GCがどのように機能するかを実際に理解するには、CFメモリ管理に関するMSDNWebキャストを参照することをお勧めします。
最も重要な側面は、割り当て率を最小限に抑えることです。オブジェクトが割り当てられるたびに、後で GC が必要になります。もちろん、オブジェクトが小さいか寿命が短い場合は、若い世代に釘付けになります (GC が世代別である場合)。大規模なオブジェクトは、テニュア アリーナに直接移動する傾向があります。しかし、収集する必要がまったくないことはさらに良いことです。
また、スタックに何かを投げることができれば、GC への負担が大幅に軽減されます。GC オプションを試してみることもできますが、割り当てプロファイラーを手元に置いておくと、問題を引き起こしている場所を見つけることができるので、はるかに役立つと思います。
注意すべきことは、標準ライブラリとフレームワークの重みです。いくつかのオブジェクトをラップすると、すぐにいっぱいになります。何かが GC ヒープに移動するたびに、通常は GC ブックキーピング用にもう少し多くのスペースが使用されることを覚えておいてください。したがって、個別に割り当てられた 1000 個のポインターは、同じポインターの配列/ベクトルよりもはるかに大きくなります。これは、後者が GC ブックキーピングを共有できるためです。一方、後者はおそらくもっと長く生き続けるでしょう。
重要な事実の1つは、オブジェクトの存続期間をできるだけ短くすることです。
構造体とクラスの問題は複雑です...たとえば、より多くのスタックスペースを簡単に使用してしまう可能性があります。そして、あなたは確かに可変構造体を望んでいません。しかし、他の点は、それに対応するためにデザインを形から曲げない限り、理にかなっているように見えます。
[編集]もう1つの一般的な落とし穴は、文字列の連結です。ループで連結を行う場合は、StringBuilderを使用します。これにより、多くの中間文字列が削除されます。GCがストリングのすべての放棄されたバージョンを収集するのに忙しいのかもしれませんか？
もう 1 つのオプションは、GC.Collect() を使用してアプリケーションの非ピーク時にガベージを手動で収集することです (これが CF で利用可能であると仮定します)。これにより、後でアプリケーションのクリーンアップに必要なオブジェクトを減らすことができます。
Rotor 2.0で.NET Rocksショーを聞きました。あなたが本当に筋金入りなら、Rotor をダウンロードし、ソースを微調整して、独自に修正したガベージ コレクターを使用することができます。
いずれにせよ、そのポッドキャストには GC に関するすばらしい情報があります。一聴することを強くお勧めします。