4

現在、dbghelpライブラリを使用して、( GetThreadContext()およびStackWalk64( )を使用して) プロセスのスレッドのスタックをウォークスルーし、各フレームに含まれる戻りアドレスのみを収集します。

ただし、そのオーバーヘッドはシステムの要求に対して大きすぎます。全体の時間は apx です。スタック ウォークごとに 5 ミリ秒 (10 ～ 15 フレーム)。この時間には、GetThreadContext() と、StackWalk64() を呼び出してすべてのフレームを取得するループが含まれます。

とにかく、もっと速くする方法を見つけなければなりません。誰でもどうすればそれができるか考えていますか?

編集：

ETW (Event Tracing for Windows) メカニズムを知っている人はいますか?

その場合、特定の期間に発生したすべてのコンテキスト スイッチを追跡するにはどうすればよいですか? 各コンテキスト スイッチでイベントを発行するイベント プロバイダーはありますか?

4

3 に答える 3

3

私が考えることができる最速の方法は、独自のバージョンをGetThreadContext作成し、監視しようとしているスレッドの構造のフィールドStackWalk64を取得するカーネル ドライバーを作成することです。これは、このテーマに関する良い記事です。kernelStackETHREAD

于 2011-12-06T22:53:42.603 に答える
2

Windows Vista 以降を使用している場合は、ETW を使用する必要があります。コンテキスト スイッチやサンプル プロファイル イベントなど、話している内容をすべて有効にすることができ、非常に効率的です。X86 の場合、基本的には EBP レジスタ チェーンを歩いています。これは、反復する必要があるアドレスのリンク リストです。64 ビット ランドでは、スタック ウォーカーはスタックをアンワインドする必要があるため、少し効率が悪くなりますが、アプリケーションで適切な量の作業を行っている場合、スタック ウォーキングの効果は現れません。上。確かにミリ秒の範囲ではありません。

于 2012-01-20T08:09:10.490 に答える
1

ETW の部分は、実際には独立した質問です。Windows パフォーマンス分析ツールは、すべてのコンテキスト スイッチと、「リソース競合同時実行プロファイリング」モードのVisual Studio プロファイラーをキャプチャできます。logman を使用してすべてのイベントを手動でファイルにダンプすることもできます。こちらの手順を参照してください。

于 2011-12-07T18:31:25.447 に答える