プロファイリングセッションの構成
プロファイリングセッションを構成するには、次のことを行う必要があります。
プロファイルするアプリケーションを dotTrace でどのように実行するかを指定します。 これは、 実行構成を使用して行うことができます。 すでに実行中のアプリケーションのプロファイルを作成する場合、この手順は必要ありません。
dotTrace でアプリケーションをどのようにプロファイリングするかを指定します: プロファイリングタイプを選択し、（任意で） その他のプロファイリングオプションを設定します（時間計測タイプ、プロセス フィルターなど）。
1. 実行構成の作成
実行構成は、プロファイル対象のアプリケーションを dotTrace でどのように実行するかを指定する方法です。 例: スタンドアロン .NET アプリケーションの実行構成には、アプリケーション実行可能ファイルへのパス、コマンドライン引数、アプリケーション作業ディレクトリへのパスが含まれます。
プロファイルされたアプリケーションの実行構成がすでにある場合は、 プロファイルするものを選択する新しいプロセスの実行 からこの実行構成を選択します。 それ以外の場合は、以下の手順に従って実行構成を作成します。
実行構成の作成方法
プロファイルするものを選択する、 新しいプロセスの実行 で、
実行構成の追加 をクリックします。新規実行構成 ウィザードで、アプリケーションタイプを選択し、アプリケーションオプションを指定します。
保存 をクリックします。 これにより、実行構成が作成および保存されます。 次回このアプリケーションのプロファイルを作成する必要がある場合は、 新しいプロセスの実行 リストから作成した構成を選択します。
2。 プロファイリングタイプの選択
プロファイル方法を選択してくださいプロファイリングタイプ でプロファイリングタイプを選択します。
プロファイリングタイプは、dotTrace がプロファイリングデータを収集する方法と、その結果として収集されるデータの量とタイプを定義します。 次の表は、最適なプロファイリングタイプを選択できます。 詳細については、 基本: プロファイリングタイプ を参照してください。
説明 | ユースケース | |
|---|---|---|
タイムライン | スレッドの状態、アプリケーションイベント、その他のマルチスレッドデータに関する一時データを収集します。 Windows では、タイムラインプロファイリングは Event Tracing for Windows (ETW) に基づいており、管理者権限で JetBrains ETW ホストサービスを実行する必要があります。 macOS および Linux では、外部サービスは必要ありません。 ネイティブプロファイリングをサポートします。 | ほとんどの場合に推奨されます。 特に、マルチスレッドアプリを分析する場合に有効です。 たとえば、UI のフリーズ、過剰なガベージコレクション、不均一なワークロード分散、不十分な I/O などの原因を特定する場合に使用します。 |
ネイティブアプリケーションをプロファイリングする場合、サンプリング | 正確な時間測定、呼び出し数の測定は行われません。 | ほとんどの場合に推奨されます。 アプリのパフォーマンスの問題を初めて探すときに理想的です。 |
プロファイラーをプロセスにアタッチする場合、トレース | 正確なコールは測定をカウントし、時間測定はプロファイリングオーバーヘッドのために不正確になる場合があります。 | サンプリングデータが足りないとき。 例: アルゴリズムの複雑さを分析するため（呼び出し回数に関する情報が呼び出し時間の値よりも価値がある場合）。 |
1 行ずつ | Windows のみ。 各コード行が測定されますが、プロファイラーのオーバーヘッドが大きいため、呼び出し時間の値は正確ではありません。 オーバーヘッドを下げるために、 フィルターを使用して特定のメソッドのみをプロファイリングできます。 | 高度なユースケースのみ。 例: どの機能が問題を引き起こしているのかを知っていて、その各行を分析したいとき。 |
3. 他のプロファイリングオプションを構成する
- サンプリングレート
（Windows 上のタイムライン）
dotTrace は Windows カーネルからスタックトレースデータを取得します。 デフォルトでは、カーネルは 1 秒あたり 1000 個のサンプルイベントを提供します。 サンプリングレートを最大 8000 サンプル / 秒まで増やすことができます。 これは、たとえばゲーム開発で、高速に実行されるネイティブコードをプロファイリングする場合に理にかなっています。 サンプリングレートが高いほど、結果の精度は高くなりますが、スナップショットのサイズは大きくなります。
- コントロールプロファイリング
手動 (デフォルト)
プロファイリングコントローラーウィンドウのボタンを使用して、プロファイリングセッションを制御します。 例: スナップショットを撮るには、 スナップショットを取得して待機する をクリックします。
API の使用力
プロファイルされたアプリケーションのコードから直接プロファイリングを制御します。 例：コードの正確なポイントでスナップショットを取得するには、
MeasureProfiler.SaveData()関数を呼び出します。 API によるプロファイリングプロセスの制御での API の使用の詳細を参照してください。Linux および macOS 上のスタンドアロンアプリケーションのタイムラインプロファイリングタイプでは使用できません。
- 時間測定
（サンプリング、Windows 上のトレース、行単位）
このオプションは、dotTrace が呼び出し時間を計算する方法を定義します。 通常、これは、スレッドが動作していないときに dotTrace が時間を計算するかどうかの選択です。 詳細については、 基本: 時間測定 を参照してください。
リアルタイム (パフォーマンスカウンタ)
推奨。 dotTrace は、メソッドの開始から終了までの間に経過した全体的な実時間を計算します。 この時間は、アプリのスレッドの状態に依存しません。 時間は、システムパフォーマンスカウンターを使用して計算されます。
リアルタイム (CPU 命令)
dotTrace は、メソッドの開始から終了までの間に経過した全体的な実時間を計算します。 この時間は、アプリのスレッドの状態に依存しません。 時間は CPU レジスタを使用して計算されます。
スレッド時間
dotTrace は特定のスレッドが実行中の時間のみを計算します。 スレッドが待機中またはスリープ中の時間は計算に含まれません。
スレッドサイクル時間
dotTrace は特定のスレッドが実行中の時間のみを計算します。 スレッドが待機中またはスリープ中の時間は計算に含まれません。 時間は CPU レジスタを使用して計算されます。
- インライン化を有効にする
（トレース、行単位）
dotTrace で JIT インライン化をオフにし、アプリケーションのソースコードの構造に近い呼び出しスタックを取得する場合は、このオプションをオフにします。
- 高精度
（トレース、行単位）
選択すると、dotTrace はより多くの時間サンプルを取得して、プロファイラー自体で費やされた時間を考慮します。
- ネイティブプロファイリングを有効化する
（タイムライン、Windows 上の Unity/Mono）
選択した場合、dotTrace はネイティブのコールスタックデータを収集します。 結果のスナップショットには、マネージドコールスタックとネイティブコールスタックの両方が含まれます。 このプロファイリングオプションは、Unity ゲームのパフォーマンスの問題を見つけるのに役立つ場合があります。
- ネイティブ割り当てを収集する
（Windows 上のタイムライン）
選択すると、dotTrace は、プロファイリングされたアプリケーションがネイティブ (アンマネージド) ヒープ内で行うすべてのメモリ割り当てに関する情報を収集します。
... KB ごとのサンプル割り当て は、メモリ割り当てサンプルをトリガーする割り当てメモリのサイズを定義します。 デフォルト値は 100 KB です。 これは、割り当てられたメモリのサイズが合計 100 KB を超えるとサンプルがトリガーされることを意味します。 例: ネイティブスレッドは、プロファイリング中に 50 KB のメモリブロックを 5 つ割り当てます。 そのような場合、dotTrace は 100 KB の 2 つの割り当てのみを検出します。
サイズが小さいほど、結果はより正確になり、スナップショットは大きくなります。 このオプションを使用して、データの精度とスナップショットサイズ間の最適なバランスを見つけます。
未リリースの割り当てのみ収集する を選択した場合、dotTrace は、スナップショットを作成した時点でまだアンマネージヒープ内にあった割り当てに関するデータのみをスナップショットに保存します。
- TPL イベントを収集する
（タイムライン）
選択すると、プロファイリングのパフォーマンスに影響する可能性がありますが、dotTrace はタスク並列ライブラリ (TPL) データを収集します。 選択を解除すると、 呼び出しツリー に
Taskノードは表示されなくなり、async呼び出しノードは await 部分と 継続 部分なしで表示されます。アプリケーションがマルチタスクを使用しない場合、またはこの情報が必要ない場合は、このオプションをクリアしてください。
- デバッグ出力を収集する
（Windows 上のタイムライン）
選択すると、dotTrace はプロファイリングされたアプリケーションが デバッグ出力に送信するすべてのメッセージに関する情報を収集します。
- シンボルファイルのダウンロード
（Windows 上のタイムライン）
PDB ファイル (またはシンボルファイル) を使用すると、コールツリーでネイティブ関数を確認できます。 これは、 ネイティブアプリケーションと、ネイティブコードを呼び出すマネージドアプリケーションに関係します。 シンボルファイルのダウンロード を選択すると、dotTrace はスナップショットを取得した直後にリモートサーバーから PDB ファイルのダウンロードを試みます。 ファイルのサイズによっては、これにはかなりの時間がかかる場合があることに注意してください。
デフォルトでは、dotTrace は
_NT_SYMBOL_PATH環境変数で指定された場所で PDB ファイルを検索します。 または、 シンボルファイルの場所を編集する を使用してカスタムローカルまたはリモートの場所を指定することもできます。バックグラウンドでダウンロード が有効になっている場合、dotTrace はプロファイリングセッションの実行中にシンボルファイルのダウンロードを開始します。 これは、スナップショットの取得時間を短縮するのに役立つ場合があります。
- 最初からプロファイリングデータを収集する
選択した場合、dotTrace は起動直後にプロファイリングデータの記録を開始します。 それ以外の場合、dotTrace は、プロファイリングコントローラーウィンドウで 開始 をクリックした後にのみ、これらのデータの収集を開始します。
4. (オプション) プロセスフィルターを構成する
プロファイルされたアプリケーションが多数のプロセスを作成する場合は、 プロセスフィルター 設定を使用して、プロファイルするプロセスを指定します。 事前定義されたフィルターを選択するか、新しいフィルターを作成することができます。
プロセスフィルターは、選択した実行構成で指定されたアプリケーションタイプによって動作が異なることに注意してください。
アプリの種類 | 説明 |
|---|---|
dotTrace は、指定されたフィルターに一致するプロセスのみをプロファイルします。 フィルターは、プロファイルされたプロセスのプロセスツリー全体（子プロセスを含む）に適用されます。 例: 多数の子プロセスを作成するマネージドプロセスがあります。 メインプロセスだけでなく、名前に | |
このモードでは、プロファイリングセッションを開始しても、プロファイリングされたプロセスは開始されません。 代わりに、dotTrace はオペレーティングシステムで最初に開始された管理対象プロセスを待機し、そのプロセスにアタッチします。 特定の プロセスフィルター が選択されると、dotTrace はフィルターに一致する最初のプロセスにアタッチします。 例えば、インクルードフィルター： | |
プロセスフィルターは適用されません。 |
プロセスフィルターを選択するには
プロファイル方法を選択してください、 拡張オプション で、 プロセスフィルター リストを開きます。
必要なフィルターを選択します。
dotTrace には、事前定義されたフィルターが 2 つ用意されています：
デフォルト: プロセスフィルターは適用されません。
プロセスツリー全体 ：dotTrace は、子プロセスを含むプロセスツリー全体をプロファイルします。 .NET プロセス 実行構成が選択されている場合、dotTrace はシステムで開始された最初の管理対象プロセス（すべての子プロセスを含む）にアタッチしてプロファイルします。
プロセスフィルターを作成するには
プロファイル方法を選択してください、 拡張オプション で、 プロセスフィルター リストを開きます。
フィルターの追加 を選択します。
フィルター設定を指定します。
命名: フィルター名。
プロセスツリー全体のプロファイル ：選択すると、dotTrace は子プロセスを含むプロセスツリー全体をプロファイルします。 このオプションを無効にすることは、 .NET プロセス実行構成のフィルターを作成する場合にのみ意味があります。 この場合、dotTrace はフィルターに一致するシステム内の最初のプロセスを待機してアタッチしますが、このプロセスの子プロセスはプロファイルしません。
フィルターマスクを含める、 フィルターマスクを除外する: それに応じてフィルターマスクを含めたり除外したりします。 マスクは、次のルールに従って適用されます。
デフォルトのポリシーは「profileall」です。
インクルードマスクが最初に適用されます。 除外マスクは、包含マスクによってフィルタリングされたプロセスに適用されます。
アスタリスク
*ワイルドカードを使用できます。
例:
MyServiceを除く名前にServiceが含まれるすべての子プロセスをプロファイリングするには、*Service*インクルードマスクとMyServiceエクスクルードマスクを追加します。
保存 をクリックします。
5。 (オプション) 行ごとのプロファイリングのフィルターを構成する
行ごとのプロファイリングは、特定のケースでは効果的かもしれませんが、常に時間がかかります。 プロファイリングのオーバーヘッドを最小限に抑えるために、いくつかのルールを定義することができます。 そのルールに従って、すべての関数が行ごとにプロファイリングされるのではなく、さらに調査する必要がある関数だけがプロファイリングされます。
必要な関数 / クラス / アセンブリのみに一致する 1 つまたは複数のフィルターを作成および設定できます。
行ごとのプロファイリング用のフィルターを作成するには
プロファイル方法を選択してください で、 1 行ずつ プロファイリングタイプを選択します。
フィルターを編集 をクリックします。
フィルターの編集 ダイアログで
フィルターの追加 をクリックします。フィルター型の選択:
コードをプロファイル: 指定されたコード項目をプロファイリングに含め、他のすべてのコード項目を除外します。
コードをプロファイルしない: 指定されたコード項目をプロファイリングから除外します。
属性でマークされたコードをプロファイルしない: 指定された属性を持つコードアイテムをプロファイリングから除外します。
最初の 2 つのオプションのいずれかを選択した場合は、プロファイリングに含めるか除外するアセンブリ、クラス、メソッドを指定します。 コード項目は互いに独立してフィルター処理されます。 例: メソッドを指定し、アセンブリとクラスにアスタリスク
*を残すと、指定した名前のメソッドがすべてのアセンブリとすべてのクラスから除外されます。最後のオプションを選択した場合は、プロファイリングからシンボルを除外するために使用する属性の名前を指定します。 オプションで、この属性が宣言されているアセンブリ名を指定します。
フィルターでコード項目名を指定する際には、アスタリスクワイルドカードを使用できます：
*（アスタリスク）は 0 文字以上の文字を表します。 例えば、*.Testsワイルドカードを使うと、すべてのテストプロジェクトがコード解析対象から除外されます。OK をクリックします。