基本: プロファイリングタイプ

dotTrace は、コールスタックデータのサンプルを定期的に取得します。

長所:

• 関数実行時間の正確な測定

• 小さなスナップショット

• 非常に軽量です：メモリ使用量が少なく、プロファイラーでアプリケーションを実行するのに必要な時間は大幅に変わりません。

短所:

• 関数の呼び出し回数は測定されません

• すべてのコールスタックと関数がキャプチャーされるわけではありません

• ETW イベント、TPL イベント、ネイティブ関数に関する情報はありません。

いつ使用するか:

アプリケーション全体のパフォーマンスを評価し、最も明白なパフォーマンスのボトルネック (つまり、最も遅い関数) を見つけます。

サンプリングは、サンプルを取得するプロセスまたは手法です。 サンプルは、プロファイリングセッション中に取得されたコールスタックのセットです。 (1) 与えられた 2 つのサンプル間の休止時間と (2) サンプルを取得するのにかかる時間。 これらの質問に対する答えは、サンプリング方法の精度を見積もるのに役立ちます。

dotTrace は、プロセス内のすべての既存スレッドの呼び出しスタックを、一時停止せずに順番に取得します。 ロックされているかスリープ状態にあるスレッドも考慮します。 コールスタックをキャプチャーするために必要な時間は、スタックの深さとネイティブおよび管理スタックフレームの数に依存するため、正確には決定できません。 サンプルを取るのに必要な時間は、サンプルごとに必然的に異なり、現在実行中のスレッドの数に依存します。

dotTrace はサンプルをとる間に一時停止します。 一時停止は、dotTrace が前のサンプルのスレッドアクティビティの処理を停止した後、次のサンプルの処理を再び開始するまでの時間です。 各ポーズの長さは、5 〜 11 ミリ秒の間のランダムな値です。 ランダムな値は、コールスタックにギャップがある確率を下げるのに役立ちます。 このような一時停止の間、アプリケーションは正常に動作し続けます。

この結果の 1 つは、サンプル間の時間が少なくとも 5 ミリ秒であるため、十分に迅速に実行されるメソッドが捕捉されず、スナップショットに表示されない可能性があるということです。 ただし、dotTrace が正しい時刻データを取得することはできません。 2 つの状況が可能です。 メソッドが高速で何度も呼び出された場合、そのメソッドは捕捉され、スナップショットに表示されます。 あるメソッドが高速で、まれにしか呼び出されないメソッドは、スナップショットでは省略されますが、その時間はその親の合計時間に含まれます。 言い換えれば、メソッドの合計時間が重要な場合は、それがカウントされます。

全体として、このプロファイリングメソッドは、問題の呼び出しスタックを明らかにするのに役立つ時間データを提供しますが、多数の関数呼び出しを提供することはできません。 それでもなお、この方法は最も高速で、パフォーマンスの問題をローカライズするための第一歩です。

dotTrace は、アプリケーションイベントを記録し、アプリケーションの状態がどのように変化したかに関するデータを書き込みます。 ETW イベントに基づく。 単純すぎる – 結果として、サンプリングプロファイリングと同様のデータが得られますが、すべてのイベントがタイムラインに表示されます。

長所:

• 関数の実行時間の正確な測定。 関数呼び出しはタイムラインに表示されます

• 軽量: プロファイラーでアプリケーションを実行するのに必要な時間は大幅に変わりません

• ETW イベントデータ (メモリ割り当て、ガベージコレクション、I/O 操作などに関するデータなど) を提供します。

• TPL データを提供できます: 非同期関数の待機ブロックと継続ブロック

• コールツリーのネイティブ関数に関するデータを提供できます (シンボルファイルが必要です)

短所:

• 関数の呼び出し回数は測定されません

• すべてのコールスタックと関数がキャプチャーされるわけではありません

• スナップショットは非常に大きくなる可能性があります

いつ使用するか:

• アプリケーション全体のパフォーマンスを評価し、最も明白なパフォーマンスのボトルネック (つまり、最も遅い関数) を見つける

• ユーザーインターフェースがフリーズする原因の特定

• 過剰なガベージコレクションと I/O 操作の特定

• 不規則な作業分散、ロックの競合、シリアル化された実行など、マルチスレッドアプリケーションの問題の特定

タイムラインプロファイリングタイプは、サンプリングプロファイリングに非常に近いものです。 どちらもコールスタックデータを収集し、パフォーマンスのボトルネックを特定できます。 主な違いは、タイムラインプロファイリング中、dotTrace はそれ自体でサンプルを収集せず、Event Tracing for Windows (ETW) からアプリケーションデータを取得することです。

タイムラインプロファイリングの主な利点は、アプリケーションが行った呼び出しだけでなく、それらの呼び出しが時間内でどのように配布済みであったかも把握できることです。 これは、イベントの時系列が重要なマルチスレッドアプリケーションの動作を分析する際、非常に役立ちます。たとえば、同期遅延やUIフリーズの原因特定などです。

もう 1 つの利点は、タイムラインプロファイリングがより広範囲のデータを収集することです。 コールスタックデータに加えて、メモリ割り当て、ガベージコレクション、I/O イベントを記録します。

CLR は、特定の関数が開始されるたびに、および終了するときに dotTrace に通知します。 dotTrace は、これら 2 つの通知間の時間を測定します。

長所:

• 関数呼び出し回数の正確な測定

• すべてのコールスタックと関数はキャプチャーされますが、インライン関数は例外です

短所:

• 時間の歪みと関数呼び出し数の間の依存関係による関数実行時間の不正確な測定

• 重量級：プロファイラーでアプリケーションを実行するのにより多くの時間が必要であり、スナップショットが非常に大きくなる場合があり、メモリ使用量も高くなります

• ETW イベント、TPL イベント、ネイティブ関数に関する情報はありません

いつ使用するか:

パフォーマンスの問題が頻繁な関数呼び出しに関連している場合など、アルゴリズムの複雑さの評価。

サンプリングとは異なり、トレースは関数を中心に、より正確には関数の入力と終了を中心にして行われます。

dotTrace は、例外のために関数が終了した場合でも、関数が開始されたときと関数が終了したときに、CLR から通知を受け取ります。 これら 2 つの通知の間の時間は、関数の実行時間と見なされます。

一方では、JIT コンパイラーによってインライン化されず、その時点で実行されたすべての関数を詳細なタイミングデータと共にスナップショットで取得します。 一方、JIT コンパイラーは関数ごとに特定のプロローグとエピローグを生成するため、CLR がそのようなコードを実行するには余分な時間がかかります。 dotTrace は、合計関数時間からこの時間をカウントおよび減算しません。 その結果、合計時間が歪む可能性があります。 歪みの程度は、関数呼び出しの数に依存します。 依存関係は線形です。 関数が呼び出される回数が多いほど、歪みは大きくなります。 また、関数の実行時間が短いほど、合計時間の精度が低下する可能性があります。 例: 単純な関数 Inc() { _value++; } がありますが、何百万回も呼び出されます。 もちろん、最適化することはできますが、少し時間がかかります。 ただし、dotTrace で実行され、トレース方法が選択されている場合、この関数を呼び出すたびにオーバーヘッドが追加され、実際の関数の実行時間よりもはるかに長くなる可能性があります。 その結果、合計時間は、サンプリング方法を使用した後、またはプロファイラーを使用しない場合よりも長くなる可能性があります。

CLR は別のオーバーヘッドを引き起こす可能性があります。 CLR は、さまざまな種類の最適化を提供します。 CLR のバージョンと選択したプロファイリング方法によっては、一部の最適化が無効になったり、別の方法で実行されたりするため、結果が異なる場合があります。

全体として、常に正しい関数呼び出し数が得られますが、関数の合計時間は不正確になる場合があります。 トレースはサンプリングよりも時間がかかり、アプリケーションの速度が大幅に低下する可能性があるため、アプリケーションの個々の部分または特定のシナリオをプロファイリングすることをお勧めします。

dotTrace は、各コード行の実行時間を測定します。

長所:

• 関数を詳細に研究する機能

短所:

• 関数実行時間の不正確な測定

• 極めて重量級：トレースと比べてプロファイラーでアプリケーションを実行するのにさらに多くの時間が必要となり、スナップショットも大きく、メモリ使用量もトレースより高くなります。

• ETW イベント、TPL イベント、ネイティブ関数に関する情報はありません。

• PDB ファイルが必要です

いつ使用するか:

たとえば、特定の関数内だけのパフォーマンスを分析したいときなどの高度なケース。

このメソッドはトレースと似ていますが、ここでは調査の対象は関数ではなくステートメントです。 ラインごとに関数をプロファイルするために、dotTrace は PDB ファイルを必要とします。 対応する PDB ファイルがない場合、このメソッドはトレースとして機能します。

dotTrace は、 声明の実行に必要な時間と実行回数を測定します。 想像することができるように、この方法は、dotTrace が各ステートメントに対して時間カウント作業を実行するため、トレースよりもさらに遅くなります。

行ごとは、調査の範囲を狭め、特定の機能に焦点を合わせたい場合に効果的な方法です。