6

Debugging performance problems using a standard debugger is almost hopeless since the level of detail is too high. Other ways are using a profiler, but they seldom give me good information, especially when there is GUI and background threads involved, as I never know whether the user was actually waiting for the computer, or not. A different way is simply using Control + C and see where in the code it stops.

What I really would like is to have Fast Forward, Play, Pause and Rewind functionality combined with some visual repressentation of the code. This means that I could set the code to run on Fast Forward until I navigate the GUI to the critical spot. Then I set the code to be run in slow mode, while I get some visual repressentation of, which lines of are being executed (possibly some kind of zoomed out view of the code). I could for example set the execution speed to something like 0.0001x. I believe that I would get a very good visualization this way of whether the problem is inside a specific module, or maybe in the communication between modules.

Does this exist? My specific need is in Python, but I would be interested in seeing such functionality in any language.

4

3 に答える 3

4

「クリティカル スポットへの早送り」機能は、どのデバッガにも既に存在し、「ブレークポイント」と呼ばれます。実際、実行速度を低下させるデバッガはありますが、コンピュータの速度を低下させないため、パフォーマンスの問題のデバッグには役立ちません。プロセッサ、ディスク、およびメモリは以前とまったく同じように低速ですが、デバッガーがコードの各行の間に遅延を挿入するだけです。これは、コードのすべての行が突然ほぼ同じ時間かかることを意味し、パフォーマンスの問題がどこにあるかの痕跡を隠すことを意味します。

パフォーマンスの問題を見つける唯一の方法は、アプリケーションで実行されたすべての呼び出しと、それにかかった時間を記録することです。これは、プロファイラーが行うことです。確かに、プロファイラーを使用するのは難しいですが、おそらくこれ以上の選択肢はありません。理論的には、すべての呼び出しとすべての呼び出しのタイミングを記録し、巻き戻しで前後に再生できますが、それは驚くほどの量のメモリを使用し、実際にはプロファイラーが行う以上のことは何もわかりません (実際、特定の種類のパフォーマンスの問題を見逃す可能性があるため、あまり意味がありません)。

プロファイラーを使用すると、時間がかかっている原因を特定できるはずです。これは、特定の関数呼び出しが多くの処理を行うために時間がかかる場合と、時間がかかるシステム呼び出しが何か (ネットワーク/ディスク) が遅くなる場合の両方であることに注意してください。または、非常に高速な呼び出しが何度も何度も呼び出される可能性があります。プロファイラーは、これを理解するのに役立ちます。ただし、クリティカル セクションでのみプロファイラーをオンにすることができ (ノイズが減る)、そのクリティカル セクションを何度も実行できる (精度が向上する) 場合に役立ちます。

于 2011-03-24T09:43:23.627 に答える
1

アプリの実行に時間がかかりすぎるフェーズがあると思います-つまり、それはあなたを待たせます。あなたが本当に望んでいるのは、より速くするために何を変更できるかを確認することだと思います。

機能する手法は、ランダム一時停止です。デバッガーの下でアプリを実行し、待機する実行の一部でアプリを一時停止し、コール スタックを調べます。これを数回行います。

プログラムが必要以上に時間を費やしている可能性があるいくつかの方法を次に示します。

  • あなたが知らなかった、そして本当に必要としなかった I/O。
  • オブジェクトの割り当てと解放を頻繁に行う。
  • データ構造に関するランナウェイ通知。
  • 他にも多すぎて言及できません...

それが何であれ、それが起こっているときは、コール スタックを調べればわかります。それが何であるかがわかれば、それを行うためのより良い方法を見つけることができます。または、まったく行わないこともできます。

プログラムが 1 秒かかる可能性があるのに 5 秒かかっている場合、各一時停止で問題が発生する確率は 4/5 です。実際、複数のスタック サンプルで見られる関数呼び出しは、それを避けることができれば、大幅に高速化されます。そして、考えられるほぼすべてのボトルネックは、この方法で見つけることができます。

関数のタイミングや呼び出される回数について考えないでください。スタックに頻繁に現れる、不要なコード行を探します。

例の追加: スタックから 5 つのサンプルを取得し、そのうちの 2 つにコード行が表示されている場合、時間の約 2/5 = 40% を担当します。正確な割合はわかりませんし、知る必要もありません。(技術的には、平均して (2+1)/(5+2) = 3/7 = 43% です。悪くはありません。どこにあるかは正確にわかります。)

于 2011-03-24T13:17:48.703 に答える
1

あなたが説明している方法とコメントの多くは、パフォーマンスへの影響を理解するための比較的弱い確率的試みのように思えます。プロファイラーは、GUI やその他のアイドル スレッド プログラムに対して完全に機能しますが、それらを読み取るには少し練習が必要です。ただし、最善の策はそこにあると思います-プロファイラーをより適切に使用することを学び、それが目的です.

あなたが説明する特定の用途は、単にプロファイラーをアタッチすることですが、まだ記録しないでください。問題のポイントに GUI を移動します。プロファイラーの記録ボタンを押してアクションを実行し、記録を停止します。結果を表示します。修理。再びそれを行う。

于 2011-03-24T13:29:44.390 に答える