gprofを使用してc++関数のプロファイリングを試みていますが、％timeに興味があります。私は複数回実行しましたが、何らかの理由で結果に大きな違いがありました。何が原因なのかわかりません。サンプリングレートを想定しているか、他の投稿でI/Oがそれと関係があると読んでいます。それで、それをより正確にして、どういうわけかほぼ一定の結果を生成する方法はありますか？
私は次のことを考えていました：
入力を待っています
よろしく
gprof ペーパーのコピーを印刷して、注意深く読むことをお勧めします。
論文によると、gprof が時間を測定する方法は次のとおりです。PC をサンプリングし、各ルーチンに到達するサンプルの数をカウントします。サンプル間の時間で乗算されます。これは、各ルーチンの合計セルフ時間です。
また、ルーチン B が-pgオプションによってインストルメント化されていると仮定して、ルーチン A がルーチン B を呼び出した回数を呼び出しサイト別に表に記録します。これらを合計すると、ルーチン B が呼び出された回数がわかります。
呼び出しツリーの最下部 (合計時間 = 自己時間) から開始して、各ルーチンの呼び出しごとの平均時間を呼び出し回数で割った合計時間と見なします。
次に、それらのルーチンの各呼び出し元に戻ります。各ルーチンの時間は、その平均自己時間に各従属ルーチンへの平均呼び出し数を加えたもので、従属ルーチンの平均時間を掛けたものです。
再帰 (コール グラフのサイクル) が存在しない場合でも、平均時間と平均呼び出し回数に関する仮定、およびインストルメント化されているサブルーチンに関する仮定など、これがエラーの可能性に満ちていることがわかります。アウト。再帰がある場合、それらは基本的に「忘れてください」と言います。
このテクノロジーのすべては、たとえ問題がなかったとしても、疑問を投げかけます - その目的は何ですか? 通常、目的は「ボトルネックを見つける」ことです。この論文によると、人々が代替の実装を評価するのに役立つ可能性があります。それはボトルネックを見つけることではありません。頻繁に呼び出されるルーチンや、平均時間が長いルーチンを調べることをお勧めします。確かに、平均累積時間が低いルーチンは無視する必要がありますが、それでは問題があまり局所化されません。そして、実行されるすべての I/O が間違いなく必要であるかのように、I/O を完全に無視します。
したがって、あなたの質問に答えるには、 Zoomを試してみてください。測定値の統計的ノイズを排除することは期待しないでください。
gprof はシンプルで堅牢な由緒あるツールですが、当初の問題はまだ残っており、その間の数十年ではるかに優れたツールが登場しました。 ここに問題のリストがあります。
gprof は、特に小さな関数の場合、あまり正確ではありません。http: //www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC11 を参照してください。
これが Linux の場合は、コードをインストルメント化する必要のないプロファイラー ( Zoomなど) をお勧めします。30 日間の無料評価ライセンスを取得できますが、その後は費用がかかります。
すべてのサンプリング プロファイラーは、統計的な不正確さから影響を受けます。エラーが大きすぎる場合は、サンプリング間隔を長くしたり、サンプリング間隔を短くしたりする必要があります。