3

あまりにも頻繁に、いくつかの新しいフレームワークとその「ベンチマーク」に関するステートメントを読みます。私の質問は一般的なものですが、次の特定の点についてです。

  1. パフォーマンスを測定するためにコードを効果的に計測するには、開発者はどのようなアプローチを取る必要がありますか？

  2. ベンチマークとパフォーマンステストについて読むとき、実際の結果を表していない可能性があることに注意すべきいくつかの危険信号は何ですか？

4

2 に答える 2

4

パフォーマンスを測定するには、コードインストルメンテーションを使用する方法とサンプリングを使用する方法の2つがあります。

私が過去に使用した商用プロファイラー（Hi-Prof、Rational Quantify、AQTime）は、コードインストルメンテーションを使用し（一部はサンプリングも使用できます）、私の経験では、これにより最良で最も詳細な結果が得られます。特にRationalQuantityを使用すると、結果を拡大したり、サブツリーに焦点を合わせたり、完全な呼び出しツリーを削除して改善をシミュレートしたりできます...

これらのインストルメンテーションプロファイラーの欠点は、次のことです。

  • 遅くなる傾向があります（コードの実行速度は約10倍遅くなります）
  • アプリケーションのインストルメント化にはかなりの時間がかかります
  • アプリケーションで例外を常に正しく処理するとは限りません（C ++の場合）
  • DLLのインストルメンテーションを無効にする必要がある場合は、セットアップが難しい場合があります（Oracle DLLのインストルメンテーションを無効にする必要がありました）

インストルメンテーションは、メモリ割り当て、クリティカルセクションなどの低レベル関数について報告される時間を歪めることもあります...

私が使用している無料のプロファイラー（Very Sleepy、Luke Stackwalker）はサンプリングを使用しています。つまり、迅速なパフォーマンステストを実行して、問題がどこにあるかを確認する方がはるかに簡単です。これらの無料のプロファイラーは、商用プロファイラーの完全な機能を備えていません（ただし、Very Sleepyの「サブツリーに焦点を当てる」機能を自分で提出しました）が、高速であるため、非常に便利です。

現時点では、私の個人的なお気に入りはVery Sleepyで、LukeStackWalkerが2番目に来ています。

どちらの場合（計装とサンプリング）でも、私の経験は次のとおりです。

  • アプリケーションのさまざまなリリースでプロファイラーの結果を比較することは非常に困難です。リリース2.0でパフォーマンスの問題が発生した場合は、2.0が1.0より遅い正確な理由を探すのではなく、リリース2.0のプロファイルを作成して改善してみてください。
  • プロファイリングの結果を、プロファイラーの外部で実行されているアプリケーションのタイミング（リアルタイム、CPU時間）の結果と比較してはなりません。アプリケーションがプロファイラーの外部で5秒のCPU時間を消費し、プロファイラーで実行されたときにプロファイラーが10秒を消費すると報告した場合、問題はありません。アプリケーションが実際に10秒かかるとは思わないでください。
  • そのため、同じ環境で結果を一貫してチェックする必要があります。プロファイラーの外部で実行した場合、またはプロファイラーの内部で実行した場合のアプリケーションの結果を一貫して比較します。結果を混ぜないでください。
  • また、一貫した環境とシステムを使用してください。より高速なPCを入手した場合でも、アプリケーションの実行速度が低下する可能性があります。たとえば、画面が大きく、画面上でより多くの更新が必要になるためです。新しいPCに移行する場合は、アプリケーションの最後のリリース（1つまたは2つ）を新しいPCで再テストして、新しいPCに合わせて時間がどのように変化するかを把握します。
  • これは、次のことも意味します。固定データセットを使用し、これらのデータセットの改善を確認します。アプリケーションを改善すると、データセットXのパフォーマンスは向上しますが、データセットYではパフォーマンスが低下する可能性があります。場合によっては、これが許容できる場合もあります。
  • 事前にどのような結果を得たいかをテストチームと話し合ってください（私自身の質問に対するOdedの回答を参照してください）。アプリケーションのパフォーマンスを「示す/数値化する」ための最良の方法は何ですか？）。
  • 速いアプリケーションがマルチスレッドを使用し、遅いアプリケーションが使用しない場合、速いアプリケーションは遅いアプリケーションよりも多くのCPU時間を使用できることを理解してください。（前に述べたように）テスト時間について、何を測定する必要があり、何を測定しないかについて話し合います（マルチスレッドの場合：CPU時間ではなくリアルタイム）。
  • 多くの小さな改善が1つの大きな改善につながる可能性があることを認識してください。アプリケーションでそれぞれ3％の時間がかかる10個のパーツを見つけ、それを1％に減らすことができる場合、アプリケーションは20％高速になります。
于 2010-02-27T12:44:19.140 に答える
1

それはあなたが何をしようとしているのかによります。

1）一般的なタイミング情報を維持したい場合は、リグレッションに注意を払うことができます。さまざまなインストルメンテーションプロファイラーが最適です。CPU時間だけでなく、あらゆる種類の時間を測定するようにしてください。

2）ソフトウェアを高速化する方法を見つけたい場合、それは明らかに異なる問題です。メジャーではなく、検索
に 重点を置く必要があります。

  • このためには、プログラムカウンターだけでなく、（必要に応じて複数のスレッドにわたって）コールスタックをサンプリングするものが必要です。それはgprofのようなプロファイラーを除外します。

  • 重要なのは、 CPU時間ではなく、実時間でサンプリングする必要があることです。これは、I / Oが原因で、クランチが原因で時間を失う可能性が非常に高いためです。これにより、一部のプロファイラーが除外されます。

  • ユーザーの入力を待たない場合など、気になる場合にのみサンプルを取得できる必要があります。これにより、一部のプロファイラーも除外されます。

  • 最後に、そして非常に重要なのは、あなたが得る要約です。行ごとの時間の割合を取得することが不可欠です。ラインによって使用される時間のパーセントは、ラインを含むスタックサンプルのパーセントです。コールグラフを使用する場合でも、関数のみのタイミングに妥協しないでください。これにより、さらに多くのプロファイラーが除外されます。（「自己時間」を忘れ、呼び出し回数を忘れてください。これらはほとんど役に立たず、誤解を招くことがよくあります。）

問題を見つける正確さはあなたが求めているものであり、それらを測定する正確さではありません。それは非常に重要なポイントです。（害はありませんが、大量のサンプルは必要ありません。害は頭の中にあり、何をしているのかではなく、測定することを考えさせられます。）

このための優れたツールの1つは、RotateRightのズームプロファイラーです。個人的に私は手動サンプリングに依存しています。

于 2010-02-26T22:38:33.407 に答える