ARM デバイスでリアルタイム アプリケーションを使用しています。パフォーマンスは重要なので、汎用の ObjectPool クラスを使用します。
これまでは、予想できる最大サイズにプールを事前に割り当てていましたが、プールのサイズを絶対に変更しなければならないシナリオに出くわしています。
Web と SO に関する多くのソリューションを見てきましたが、サイズ変更は常に GC をトリガーする配列コピー操作であることに気付きました。これで問題ないと思いましたが、今では重要なパフォーマンス ヒットが見られ始めています。
ガベージを生成しない真のサイズ変更可能なオブジェクト プーリング ソリューション/パターンはありますか?
リンク リストを内部的に使用するオブジェクト プールをコーディングします。これにより、プールを必要なだけ大きくすることができます。そして、プールはそのリンクされたリストの先頭に追加および削除する必要があります。これにより、圧力が低い場合でも、まったく同じオブジェクトが再利用されることが保証されます。
一方、これらのオブジェクトの構築および/または破棄には費用がかかりますか? そもそもプールを使用する理由の 1 つは、作成と破棄にコストがかかるオブジェクトを管理するためです。
プールを使用するもう 1 つの主な理由は、オブジェクトの再利用です。ほとんどの場合、プールから最初のオブジェクトを取得し、これらのオブジェクトが CPU キャッシュで利用できることを期待しています。プール内のオブジェクトが不足しているという事実は、プールを使用してもあまりメリットがないことを示唆しています。
したがって、新しいオブジェクト プールでコーディングを開始する前に、プールを削除してみて、GC に魔法をかけてパフォーマンスにどのような影響があるかを確認することをお勧めします。