Alternatives to gprof [closed] Ask Question

gprof (read the paper) exists for historical reasons. If you think it will help you find performance problems, it was never advertised as such. Here's what the paper says:

The profile can be used to compare and assess the costs of various implementations.

It does not say it can be used to identify the various implementations to be assessed, although it does imply that it could, under special circumstances:

especially if small portions of the program are found to dominate its execution time.

What about problems that are not so localized? Do those not matter? Don't place expectations on gprof that were never claimed for it. It is only a measurement tool, and only of CPU-bound operations.

Try this instead.
Here's an example of a 44x speedup.
Here's a 730x speedup.
Here's an 8-minute video demonstration.
Here's an explanation of the statistics.
Here's an answer to critiques.

プログラムについて、簡単な観察があります。特定の実行では、すべての命令が全体の時間の一部を占めます (特にcall命令)。つまり、命令がなければ、時間は消費されないということです。その間、命令はスタック上にあります。これが理解されると、次のことがわかります。

gprofパフォーマンスに関する次のような神話が体現されています。

1. プログラムカウンタのサンプリングが便利です。
   これは、スカラー値の大きな配列のバブルソートのような、不要なホットスポットボトルネックがある場合にのみ役立ちます。たとえば、文字列比較を使用してソートに変更すると、それはまだボトルネックですが、プログラムカウンタのサンプリングでは、ホットスポットが文字列比較にあるため、それを検出しません。一方、延長プログラム カウンター (呼び出しスタック)、文字列比較が呼び出されるポイント、ソート ループが明確に表示されます。実際には、gprofPC のみのサンプリングの制限を改善するための試みでした。

2. 時間のかかるコード行をキャプチャするよりも、関数のタイミングの方が重要です。
   その神話の理由はgprofスタックサンプルをキャプチャできなかったため、代わりに関数の時間を計測し、その呼び出し回数をカウントし、呼び出しグラフをキャプチャしようとしました。ただし、コストの高い関数が特定されたら、その関数内で時間の原因となっている行を調べる必要があります。調べる必要のないスタックサンプルがあれば、それらの行はサンプル上にあります。(一般的な関数には 100 - 1000 個の命令があります。関数電話は 1 つの命令なので、コストのかかる呼び出しを見つけるものは 2 ～ 3 桁正確になります。

3. コールグラフが重要であること。
   プログラムについて知っておくべきことはどこそれは時間を費やすが、なぜ関数内で時間を費やしているとき、スタック上のコードの各行は、その行がそこに存在する理由の連鎖における 1 つのリンクを提供します。スタックの一部しか表示できない場合、理由の一部しか表示できないため、その時間が実際に必要かどうかを確実に判断することはできません。呼び出しグラフから何がわかるでしょうか。各アークは、関数 A が関数 B を呼び出す処理中であったことを示しています。A に B を呼び出すコード行が 1 行しかない場合でも、その行は理由のごく一部しか示しません。運が良ければ、その行の理由はよくありません。通常、よくない理由がある場合、それを見つけるには複数の行を同時に確認する必要があります。A が複数の場所で B を呼び出す場合、わかることはさらに少なくなります。

4. 再帰は扱いにくく混乱を招く問題です。
   それはgprof他のプロファイラーは、呼び出しグラフを生成し、ノードに時間を帰属させる必要があると認識しています。スタックのサンプルがある場合、サンプルに表示される各コード行の時間コストは非常に単純な数値、つまり、その行が含まれるサンプルの割合です。再帰がある場合、特定の行がサンプルに複数回表示されることがあります。関係ない。サンプルがNミリ秒ごとに取得され、そのF%に線が現れる（単独または複数）と仮定します。その線が時間をかけずに済む場合（削除したり、その線を迂回するなど）、それらのサンプルは消える、時間は F% 短縮されます。

5. 時間測定の精度（したがってサンプル数が多いこと）が重要である。
   ちょっと考えてみてください。あるコード行が5つのサンプルのうち3つに現れた場合、それを電球のように発射できれば、およそ60%の時間が節約できます。さて、別の5つのサンプルを取った場合、2回、または4回しか見られなかったかもしれません。したがって、60%の測定値は、40%から80%の範囲に近くなります。40%だけだった場合、その問題を修正する価値がないと言えるでしょうか。では、本当に必要なのは、問題を見つける? 500 または 5000 のサンプルであれば、より正確に問題を測定できますが、より正確に問題を発見することはできません。

6. ステートメントまたは関数の呼び出しをカウントすることは有用です。
   ある関数が 1000 回呼び出されたことがわかっているとします。そこから、どのくらいの時間がかかるかわかりますか? また、平均して実行にどのくらい時間がかかるかも把握し、その時間をカウントで乗算し、合計時間で割る必要があります。平均呼び出し時間はナノ秒から秒まで変化する可能性があるため、カウントだけではあまり意味がありません。スタック サンプルがある場合、ルーチンまたはステートメントのコストは、それが実行されるサンプルの一部にすぎません。その時間の一部は、ルーチンまたはステートメントをまったく時間がかからないようにすることができれば、原理的には全体的に節約できる時間であり、これがパフォーマンスと最も直接的な関係があります。

7. ブロックされている場合はサンプルを採取する必要がない
   この神話の理由は2つあります。1) プログラムが待機しているときはPCサンプリングは無意味であること、2) タイミングの正確さへのこだわりです。ただし、(1) の場合、プログラムはファイルI/Oなど、要求した何かを待っている可能性があり、知っておく必要があります、およびスタック サンプルが明らかにするもの。(当然、ユーザー入力を待っている間のサンプルは除外する必要があります。) (2) の場合、プログラムが他のプロセスとの競合のために待機しているだけであれば、実行中にかなりランダムに発生すると考えられます。したがって、プログラムの所要時間は長くなる可能性がありますが、重要な統計、つまりステートメントがスタック上にある時間の割合に大きな影響を与えることはありません。

8. 「自分の時間」が大切だということ
   セルフ時間は、行レベルではなく関数レベルで測定している場合にのみ意味があり、関数時間が純粋にローカルな計算に使われるのか、それとも呼び出されたルーチンに使われるのかを判断するのに助けが必要だと思う場合です。行レベルで要約すると、行がスタックの末尾にある場合はセルフ時間を表し、そうでない場合は包括的な時間を表します。いずれにしても、コストはスタック サンプルのパーセンテージであるため、どちらの場合でも、それが見つかります。

9. サンプルを高頻度で採取する必要がある
   これは、パフォーマンスの問題はすぐに発生する可能性があり、その問題に遭遇するにはサンプルを頻繁に取得する必要があるという考えに基づいています。ただし、問題が合計実行時間 10 秒 (または任意の時間) のうち 20% を占めている場合、その合計時間内の各サンプルが問題に遭遇する確率は 20% になります。これは、問題がこのように 1 つの部分で発生するか
   .....XXXXXXXX...........................
.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^(20 サンプル、4 ヒット)
   、またはこのように多数の小さな部分で発生するか
   X...X...X.X..X.........X.....X....X.....
.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^(20 サンプル、3 ヒット)
   に関係なく同じです。いずれの場合も、取得されるサンプルの数に関係なく、ヒット数は平均して約 5 分の 1 になります (平均 = 20 * 0.2 = 4。標準偏差 = +/- sqrt(20 * 0.2 * 0.8) = 1.8)。

10. あなたが探しているもののボトルネック
    は、1 つしかないかのように動作します。次の実行タイムラインを考えてみましょう。vxvWvzvWvxvWvYvWvxvWv.vWvxvWvYvW
    これは、 で表される実際に役立つ作業で構成されています.。パフォーマンスの問題がありvWxYz、それぞれ 1/2、1/4、1/8、1/16、1/32 の時間がかかります。サンプリングによりがv簡単に見つかります。これは削除され、 が残ります。
    xWzWxWYWxW.WxWYW
    これで、プログラムの実行時間は半分になり、所要W時間も半分になり、 が簡単に見つかります。これは削除され、 が残ります。
    xzxYx.xY
    このプロセスは、削除する問題がなくなるまで、パーセンテージで最大となるパフォーマンスの問題を削除するたびに継続されます。これで、実行されるのは のみで.、これは元のプログラムで使用された時間の 1/32 で実行されます。これは、拡大効果問題を取り除くと分母が減るので、残りはパーセントだけ大きくなります。
    もう一つの重要な点は、あらゆる問題を見つけなければならない- 5 つのうちどれも欠けていない。問題が見つからず修正されないと、最終的なスピードアップ率が大幅に低下します。すべてではなく一部しか見つからないだけでは「十分」ではありません。

追加：私はただ1つの理由を指摘したい。gprofは人気があり、おそらく無料で教えやすく、長い間存在してきたため、教えられています。Google で簡単に検索すると、それを教えている (または教えているように見える) 学術機関がいくつか見つかります。

バークレー、BU、クレムソン、コロラド、デューク、アーラム、FSU、インディアナ、MIT、MSU、NCSA、イリノイ、NCSU、ニューヨーク、OU、プリンストン、PSU、スタンフォード、UCSD、UMD、ミシガン大学、ユタ、テキサス、UTK、WUSTL

** 痕跡を残さない他の方法で仕事を依頼する場合を除き、なぜメッセージの投稿などにより行われます。