非同期呼び出しを分析する
非同期コードの欠点の 1 つは、プロファイルを作成してパフォーマンスを分析するのが難しいことです。 これは、非同期メソッドが実行されると、制御が別のスレッドに切り替えられて戻るため、結果の呼び出しツリーがもつれているためです。
dotTrace は非同期コードの解析を大幅に簡略化します。すべての async 呼び出しノードを 呼び出しツリー にマークし、対応する await 時間と継続コードをそのノードの下にまとめます。 つまり、異なるコールスタックを検索するのではなく、非同期呼び出しのすべての「部分」を一か所ですばやく見つけることができます。
dotTrace が非同期コードをどのように扱うかをよりよく理解するために、次の例をご覧ください（コードは左側、対応する 呼び出しツリー は右側に表示されます）：
ご覧のとおり、非同期呼び出しのすべての「部分」は Async RunAsyncOperation ノード内に表示されています。
RunAsyncOperationの合計時間は次のように計算されます119 ミリ秒 =
Init()101 ミリ秒 +ReadAsync()13 ミリ秒 +clr.dll3.7 ミリ秒 +FileStream.ctor()0.6 ミリ秒Initメソッド（101ms）はメインスレッド上で実行されるため、その時間がRunAsyncOperationの合計時間に加算されます。ReadAsyncはメインスレッドで開始されますが (13 ミリ秒)、後続のタスクはスレッドプールで実行されます。 タスクの実行 ノードの時間 (819 ms) は灰色で表示され、RunAsyncOperationの合計時間には追加されません。
この場合の await 時間は タスクの実行 時間 (819 ミリ秒) と同じですが、実際には、タスクがスケジュールに待機する時間も含まれているため、それより長くなる可能性があります。
継続 ノードは継続コードで、この場合は単一の
ProcessFileメソッド（301 ms）で構成されています。 この呼び出しはスレッドプールで実行されるため、その時間も灰色で表示され、RunAsyncOperationの合計時間には加算されません。
継続コードのバックトレース
もちろん、継続コードの バックトレース は、コールバック関数だけでなく、元の async メソッドに戻ります。 これは、継続コードが例外をスローし、その発生源を特定する必要がある場合などに非常に役立ちます。
非同期呼び出しの合計時間でフィルター処理する
非同期呼び出しの合計時間でフィルターを適用するには、 呼び出しツリー の呼び出しノードをダブルクリックするか、ノード (またはその await または 継続 ノード) を右クリックして、コンテキストメニューから Async メソッドの分析 を選択します。
async メソッドの呼び出し時間でフィルターを適用すると、dotTrace はそのメソッドが実行された時間間隔のみを残します。 呼び出しツリー に表示される対応するチェックボックスを選択することで、継続コード間隔 (および await time ノード) を含めたり除外したりできることに注意してください。
継続コードが範囲外になるようにフィルターを適用する場合 (メインスレッドによるフィルターなど)、 継続 チェックボックスは表示されないことに注意してください。
コールツリーのタスク
前述の機能は、 async/await だけでなく、 Task クラスに基づくすべてのタスクで機能します。 Run ノードには、タスクデリゲートを持つ タスクの実行 ノードが含まれています。
非同期の呼び出しとイベント
呼び出しツリー は、メモリ割り当てや例外など、タイムラインプロファイリングモードでサポートされている他のすべてのタイプのイベントだけでなく、呼び出し時間でも機能します。 例: 特定の非同期メソッドが割り当てるメモリ量を表示できます。
