ほとんどのプログラムは、サブルーチン (多くの場合、ライブラリ サブルーチン) の呼び出しに多くのサイクルを費やしているため、排他的 (自己) 時間だけを見ると、何が表示されているかがわかります。
- したがって、ポイント 1 は、包括的 (自己と呼び出し先) の時間を確認することです。
ここで、プロファイラーが「CPU プロファイラー」である場合、おそらく I/O 時間は見えません。つまり、プログラムはほとんどの時間を読み取りまたは書き込みに費やしている可能性がありますが、プロファイラーはそれについての手がかりを提供しません。
- したがって、ポイント 2 は、「CPU」時間ではなく「ウォール クロック」時間で動作するプロファイラーを使用することです。ただし、I/O をあまり行っていないことが確実でない限りはそうです。(I/O を行っていないと思うこともありますが、いくつかのサブルーチン層の奥深くで、I/O を行っていると思います。)
多くのプロファイラーは呼び出しグラフを生成しようとします。プログラムに再帰が含まれていない場合、およびプロファイラーがコード内のすべてのルーチンにアクセスできる場合、多くの原因となっているコード内のサブルーチン呼び出しを特定するのに役立ちます。時間の。ただし、ルーチン A が大きく、複数の場所で B を呼び出す場合、プロファイラーはコードのどの行を調べる必要があるかを通知しません。
- ポイント 3 は、可能であれば、行レベルの包括時間のパーセンテージを提供するプロファイラーを使用することです。(パーセンテージは最も有用な数値です。これは、何らかの方法でそのコード行を削除できた場合に節約できる全体の時間を示しているためです。また、システム内の競合するプロセスの影響をあまり受けていません。) そのようなプロファイラーの一例はズームです。
これをすべて行った後、コードを高速化するためにできることはあまりないかもしれません。ただし、データの特定のプロパティがパフォーマンスにどのように影響するかを確認できれば、さらに高速化できる可能性があることがわかります。プロファイラーはデータを見ることができません。
- 私がしていることは、デバッガーの下でプログラムの状態をランダムにサンプリングし、各サンプルでプログラムが何をしているかを本当に理解できるかどうかを確認することです。他の方法では見つけられないものを、その方法で見つけることができます。(これは正確ではないと言う人もいますが、正確です - 重要なことについてです。重要なのは、正確にいくらかかるかではなく、問題が何であるかです。) そして、それがポイント 4 です。