c# - リアルタイム .NET アプリケーションでガベージコレクションを回避するにはどうすればよいですか?

Question

ネットワークからメッセージを受信し、メッセージの種類に応じて異なるオブジェクトに変換し、最後にアプリケーションビジネスロジックを適用する金融 C# アプリケーションを作成しています。

ポイントは、ビジネスロジックが適用された後は、このインスタンスが再び必要になることはないと確信しているということです。ガベージコレクターがそれらを解放するのを待つのではなく、明示的に「削除」したいと思います。

オブジェクトのプールを使用して常に同じインスタンスのセットを再利用する必要がありますか、それともより良い戦略がありますか?

目標は、タイムクリティカルなプロセス中にガベージコレクションが CPU を使用するのを回避することです。

score 22 · Accepted Answer

それらをすぐに削除しないでください。オブジェクトごとにガベージコレクタを呼び出すのは、お勧めできません。通常、ガベージコレクターをいじりたくはありません。タイムクリティカルなプロセスでさえ、機密性が高い場合は競合状態が発生するのを待っています。

ただし、アプリの負荷が高い期間と低い期間があることがわかっている場合は、軽い期間に達したときに、より一般的な GC.Collect() を試して、次の繁忙期の前にクリーンアップを促すことができます。

score 18 · Accepted Answer

ここを見てください：http://msdn.microsoft.com/en-us/library/bb384202.aspx

ガベージコレクターに、現在重要なことを行っていることを伝えることができます。

score 11 · Accepted Answer

オブジェクトのプールを使用し、それらのオブジェクトを再利用します。これらのオブジェクトへの呼び出しのセマンティクスは、ファクトリファサードの背後に隠される必要があります。事前に定義された方法でプールを拡張する必要があります。おそらく、限界に達するたびにサイズを 2 倍にするでしょう。ハイウォーターアルゴリズム、または一定のパーセンテージです。GC.Collect() を呼び出さないことを強くお勧めします。

プールの負荷が十分に低くなると、プールを縮小でき、最終的にはガベージコレクションがトリガーされます。CLR に心配させてください。

score 7 · Accepted Answer

一般に、ガベージコレクタを推測しようとするのは非常に悪い考えです。Windows では、ガベージコレクターは世代別のものであり、非常に効率的であると信頼できます。この一般的な規則にはいくつかの注目すべき例外があります。最も一般的なのは、オブジェクトが Gen2 (最長寿命) に昇格すると、多くの古いオブジェクトが死ぬ原因になることがわかっている 1 回限りのイベントの発生です。彼らはぶらぶらする傾向があります。

あなたが言及した場合、あなたは多くの短命のオブジェクトを生成しているように聞こえます-これらはGen0コレクションになります。いずれにせよ、これらは比較的頻繁に発生し、最も効率的です。必要に応じて、オブジェクトの再利用可能なプールを用意することでそれらを回避できますが、そのようなアクションを実行する前に、GC がパフォーマンスの問題であるかどうかを確認することをお勧めします。CLR プロファイラーは、これを行うためのツールです。

ガベージコレクターは .NET フレームワークによって異なることに注意してください。コンパクトなフレームワーク (Xbox 360 およびモバイルプラットフォームで実行されます) では、ガベージコレクターは非世代 GC であるため、何についてもっと注意する必要があります。プログラムが生成するガベージ。

score 6 · Accepted Answer

GC.Collect() を強制することは一般的に悪い考えです。必要に応じて拡張できるオブジェクトのプールを使用することが最善の解決策のように思えます-私はこのパターンをうまく使用しました。

このようにして、ガベージコレクションだけでなく、通常の割り当てコストも回避できます。

最後に、GC が問題を引き起こしていると確信していますか? パフォーマンスを節約するソリューションを実装する前に、おそらくこれを測定して証明する必要があります-不要な作業を引き起こしている可能性があります!

score 5 · Accepted Answer

「目標は、タイムクリティカルなプロセス中にガベージコレクションがCPUを使用するのを避けることです」

Q:タイムクリティカルな場合、難解なハードウェアを聞いていて、割り込みを見逃すわけにはいかないということですか?

A:そうであれば、C# は使用する言語ではありません。そのためには、アセンブラー、C、または C++ が必要です。

Q:クリティカルとは、パイプに大量のメッセージがあり、ガベージコレクターによって速度が低下するのを防ぎたいという意味ですか?

A:もしそうなら、あなたは不必要に心配しています。オブジェクトの寿命が非常に短いということは、ガベージコレクターがそれらを非常に効率的にリサイクルし、パフォーマンスに明らかな遅延がないことを意味します。

ただし、確実に知る唯一の方法は、それをテストし、テストメッセージの一定のストリームを処理するように一晩実行するように設定することです。GC が開始されたときにパフォーマンス統計を見つけることができれば、私は唖然とします (できたとしても)それが実際に重要な場合、私はさらに驚くでしょう）。

score 3 · Accepted Answer

ガベージコレクターがどのように動作するかをよく理解して感じてください。そうすれば、ここで考えていることが推奨されない理由を理解できます。CLRがメモリ内のオブジェクトの再配置に多くの時間を費やすのが本当に好きでない限り。

score 3 · Accepted Answer

アプリの負荷はどれくらいですか? 3 つのサウンドカード (マネージド DirectX、44.1KHz、ステレオ、16 ビット) を 8KB ブロックでキャプチャし、3 つのストリームのうち 2 つを TCP/IP 経由で別のコンピューターに送信するアプリを作成しました。UI は、オーディオレベルメーターと (スムーズな) スクロールタイトル/アーティストを 3 つのチャンネルごとにレンダリングします。これは、XP、1.8GHz、512MB などの PC で実行されます。アプリは CPU の約 5% を使用します。

手動で GC メソッドを呼び出すことは避けました。しかし、無駄ないくつかのことを調整する必要がありました。RedGate の Ant プロファイラーを使用して、無駄な部分を絞り込みました。素晴らしいツールです！

事前に割り当てられたバイト配列のプールを使用したかったのですが、マネージド DX アセンブリが内部でバイトバッファーを割り当ててから、それをアプリに返します。する必要がないことがわかりました。

score 2 · Accepted Answer

絶対にタイムクリティカルな場合は、C /C++のような決定論的プラットフォームを使用する必要があります。GC.Collect（）を呼び出しても、CPUサイクルが生成されます。

あなたの質問は、メモリを節約したいがオブジェクトを取り除きたいという提案から始まります。これはスペースクリティカルな最適化です。GCは人間よりもこの状況を最適化するのに優れているため、本当に必要なものを決定する必要があります。

score 2 · Accepted Answer

その音からすると、C＃には存在しない決定論的ファイナライズ（C ++のデストラクタ）について話しているようです。C＃で最も近いのは、Disposableパターンです。基本的に、IDisposableインターフェースを実装します。

基本的なパターンは次のとおりです。

public class MyClass: IDisposable
{
    private bool _disposed;

    public void Dispose()
    {
        Dispose( true );
        GC.SuppressFinalize( this );
    }

    protected virtual void Dispose( bool disposing )
    {
        if( _disposed )    
            return;

        if( disposing )
        {
            // Dispose managed resources here
        }

        _disposed = true;
    }
}

score 1 · Accepted Answer

プール内の各タイプのインスタンスの量を制限し、インスタンスで既に完了したものを再利用できます。プールのサイズは、処理するメッセージの量によって異なります。

score 1 · Accepted Answer

メッセージを受け取るたびにオブジェクトの新しいインスタンスを作成する代わりに、既に使用されているオブジェクトを再利用してみませんか? こうすれば、ガベージコレクターと戦うことも、ヒープメモリが断片化することもありません。**

メッセージの種類ごとに、使用されていないインスタンスを保持するプールを作成できます。ネットワークメッセージを受信するたびに、メッセージの種類を確認し、待機中のインスタンスを適切なプールから取り出して、ビジネスロジックを適用します。その後、メッセージオブジェクトのインスタンスをそのプールに戻します。

コードを簡単にスケーリングできるように、プールにインスタンスを「遅延読み込み」することをお勧めします。したがって、プールクラスは、null インスタンスがプルされたことを検出し、渡す前にそれを埋める必要があります。次に、呼び出し元のコードがそれをプールに戻すと、それは実際のインスタンスになります。

** 「オブジェクトプーリングは、オブジェクトを割り当てたり割り当て解除したりするのではなく、再利用できるパターンです。これにより、ヒープの断片化やコストのかかる GC 圧縮を防ぐことができます。」

http://geekswithblogs.net/robp/archive/2008/08/07/speedy-c-part-2-optimizing-memory-allocations---pooling-and.aspx

score 0 · Accepted Answer

理論的には、CPU の負荷が高い場合、または本当に必要でない限り、GC は実行されるべきではありません。ただし、必要に応じて、すべてのオブジェクト (おそらくシングルトンインスタンス) をメモリ内に保持し、準備が整わない限りクリーンアップしないことをお勧めします。これが、GC がいつ実行されるかを保証する唯一の方法です。

c# - リアルタイム .NET アプリケーションでガベージ コレクションを回避するにはどうすればよいですか?

13 に答える 13

Related

Reference

c# - リアルタイム .NET アプリケーションでガベージコレクションを回避するにはどうすればよいですか?