VS2010 ProfessionalでVisioアドインに取り組んでおり、アプリケーションのデバッグ中にホットスポット（特にCOMオブジェクトの周囲）を探しています。既存の.NETアプリケーションをプロファイリングできるプロファイラーをいくつか見つけましたが、デバッグをサポートしているものはありません（私が見たもの）。さらに、これは完全なスタンドアロンの実行可能ファイルではなく.NETアドインであるため、どのように公平になるかわかりません。
私が調べたプロファイラー：
VS2010デバッグセッション中に使用できるプロファイラーを見つけた人はいますか？
私は以前にSOでこの点を指摘しましたが、他の人もそうです。
あなたの目的が実時間で測定されるパフォーマンスを改善することである場合、断然最良のツールはデバッガー自体とその「一時停止」ボタンです。その理由をお見せしましょう。
まず、優れたプロファイラーを見てみましょう
プロファイラーの中では、ANTS はおそらく最高の製品です。アプリで実行すると、画面の上部は次のようになります。
確認する期間を選択する必要があり、CPU 時間とファイル I/O 時間のどちらを確認するかを選択する必要があることに注意してください。その期間内に、次のようなものが表示されます。
これは、CPU 時間のみを考慮して、ANTS が考える「ホット パス」を示そうとしています。もちろん、包括的な「Time With Children (%)」を強調していて、それでいいのです。このような大きなコード ベースでは、セルフタイムの「時間 (%)」が非常に小さいことに注目してください。これは典型的なことであり、その理由がわかります。
つまり、包含パーセントが低い関数は無視する必要があるということです。なぜなら、それらをノーオペレーションに減らすことができたとしても、その間隔の全体的な時間は、包含パーセントを超えて減少することはないからです。
したがって、包括的な割合が高い関数を見て、一般的には a) サブ関数への呼び出しを少なくするか、b) 関数自体を呼び出すことにより、関数の中に何かを見つけて時間を短縮しようとします。以下。
何かを見つけて修正すると、一定の速度が向上します。その後、すべてをもう一度試すことができます。修正するものが何も見つからない場合は、勝利を宣言し、別の日にプロファイラーを片付けます。
さらに高速化するために修正できる問題が他にもあった可能性があることに注意してください。これらは本当に大きな枕木になる可能性があります。
それでは、いくつかのマニュアルサンプルを見てみましょう
私を悩ませていた段階で、アプリをランダムに 6 回一時停止しました。コールスタックのスナップショットを撮るたびに、プログラムが何をしているのか、なぜそれをしているのかをよく調べました。3 つのサンプルは次のようになります。
外部コード
Core.Types.ResourceString.getStringFromResourceFile 行 506
Core.Types.ResourceString.getText 行 423
Core.Types.ResourceString.ToString 行 299
外部コード
Core.Types.ResourceString.getStringFromResourceFile 行 528
Core.Types.ResourceString.getText 行 423
コア.Types.ResourceString.ToString 行 299
Core.Types.ResourceString.implicit operator string 行 404
SplashForm.pluginStarting 行 149
Services.Plugins.PluginService.includePlugin 行 737
Services.Plugins.PluginService.loadPluginList 行 1015
Services.Plugins.PluginService.loadPluginManifests 行1074
Services.Plugins.PluginService.DoStart 行 95
Core.Services.ServiceBase.Start 行 36
Core.Services.ServiceManager.startService 行 1452
Core.Services.ServiceManager.startService 行 1438
Core.Services.ServiceManager.loadServices 行 1328
Core.Services.ServiceManager.Initialize 行 346
Core.Services.ServiceManager .Start 行 298
AppStart.Start 行 95
AppStart.Main 行 42
これが何をしているのかです。リソース ファイルを読み取っています (これは I/O であるため、CPU 時間を見てもわかりません)。それを読み取る理由は、プラグインの名前を取得するためです。プラグインの名前がリソース ファイルにある理由は、将来、その文字列を国際化する必要がある可能性があるためです。とにかく、それがフェッチされている理由は、プラグインのロード中にスプラッシュ画面に名前を表示できるようにするためです。これはおそらく、ユーザーが何がそんなに時間がかかっているのか疑問に思っている場合に、スプラッシュ スクリーンに何が起こっているのかが表示されるためです。
これら 6 つのサンプルは、名前が表示されない場合、または表示されてもより効率的な方法で取得された場合、アプリの起動速度が約2 倍になることを証明しました。
測定値を表示することで機能するプロファイラーでは、これほど迅速にこの洞察を得ることができなかったことを理解していただければ幸いです。
プロファイラーが CPU ではなく実時間での包括的なパーセントを示したとしても、ユーザーは何が起こっているのかを理解しようとすることになります。やってる事なら必要です。
要約統計だけを見たり、コードを見たりするときの人間の傾向は、「それが何をしているのかはわかりますが、それを改善する方法はわかりません」と言うものです。
では、「統計的有意性」はどうでしょうか。
私はこれをいつも耳にしますが、それは統計についての素朴さから来ています。
6 つのサンプルのうち 3 つが問題を示している場合、それは、問題によって使用される可能性が最も高い実際の割合が 3/6=50% であることを意味します。また、これを何度も行った場合、平均してコストは (3+1)/(6+2) になり、これも 50% になります。時間を 50% 節約すると、2 倍のスピードアップが得られます。コストがわずか 20% になる可能性があり、その場合、速度向上はわずか 1.25 倍になります。コストが 80% にもなる確率は同じで、その場合、スピードアップは 5 倍 (!) になります。そうです、それはギャンブルです。スピードアップは見積もりよりも少ない可能性がありますが、ゼロにはならず、同様に劇的に大きくなる可能性があります。
より高い精度が必要な場合は、より多くのサンプルを取得できますが、統計的な精度を得るためにサンプルを調べることから得られる洞察を犠牲にすると、スピードアップが見られない可能性があります。
PSこのリンクは、すべての問題を見つけることの重要性を示しています。
VS2010 の Extension Manager を調べたところ、 dotTrace が見つかりました。これにより、デバッグ中に実行中のプロセス (私の場合は Visio) にアタッチできます。
このツールの 10 日間の試用版は役に立ちましたが、400 ドルではまだ少し高く感じます。私はまだ同じタスクを達成するためのより安価な方法を見つけたいと思っています.