ストップウォッチのベンチマークは受け入れられますか？
ストップウォッチベンチマークを使用する人はいますか、それともパフォーマンスツールを常に使用する必要がありますか？ Javaで利用できる優れた無料ツールはありますか？どのツールを使用していますか？
私の懸念を明確にするために、ストップウォッチのベンチマークは、オペレーティングシステムのスケジューリングが原因でエラーが発生する可能性があります。プログラムの特定の実行時に、OSは、タイミングをとっている関数の途中で別のプロセス（または複数）をスケジュールする場合があります。 Javaでは、スレッド化されたアプリケーションの時間を計測しようとすると、JVMスケジューラーがさらに少しランダム性をミックスに投入するため、状況はさらに悪化します。
ベンチマーク時にオペレーティングシステムのスケジューリングにどのように対処しますか？
ストップウォッチのベンチマークは、意味のある十分な反復を測定する場合は問題ありません。通常、1桁の秒数の合計経過時間が必要です。そうしないと、スケジューリングやその他のO/Sの中断によって、結果が簡単に大幅に歪められます。
このために、私はずっと前に作成したSystem.currentTimeMillis()に基づく静的メソッドの小さなセットを使用します。
私が使用したプロファイリング作業では、 jProfiler を何年も使用しており、非常に優れていることがわかりました。私は最近、 YourKit を調べました。これは、Webサイトからはすばらしいようですが、個人的にはまったく使用していません。
スケジューリングの中断に関する質問に答えるために、一貫性が達成されるまで繰り返し実行する/実際には、プロセスのスケジューリングから異常な結果を取り除く作業が観察されることがわかりました。また、スレッドのスケジューリングは、5〜30秒の実行に対して実際的な影響を与えないこともわかりました。最後に、数秒のしきい値のスケジューリングを過ぎた後、私の経験では、結果への影響はごくわずかです。5秒の実行は、時間/反復の5分の実行と同じ平均を一貫して示しています。
また、実際にテストされたコードが時間の経過とともに実行されると予想される回数に応じて、テストされたコードを約10,000回事前実行してJITを「ウォームアップ」することを検討することもできます。
十分な時間間隔を測定する限り、完全に有効です。合計経過時間が1秒を超えるように、テストする対象を20〜30回実行します。 System.currentTimeMillis（）に基づく時間計算は、0ミリ秒または約30ミリ秒になる傾向があることに気づきました。それ以上に正確なものは得られないと思います。本当に短い時間間隔を測定する必要がある場合は、System.nanoTime（）を試してみることをお勧めします。
- ドキュメント： http://Java.Sun.com/javase/6/docs/api/Java/lang/System.html#nanoTime（）
- System.nanoTime（）にもいくつかの問題があるため、短い期間の測定に関する質問： Javaでマイクロ秒の精度で時間を測定するにはどうすればよいですか？
ストップウォッチは実際には最高のベンチマークです！
実際のエンドツーエンドユーザーの応答時間は、実際に重要な時間です。
利用可能なツールを使用してこの時間を取得できるとは限りません。たとえば、ほとんどのテストツールには、ブラウザがページをレンダリングするのにかかる時間が含まれていないため、CSSが正しく記述されていない複雑なページでは、テストに対する1秒未満の応答時間が表示されます。ツールですが、5秒とユーザーへの応答時間。
これらのツールは、自動テストや問題の特定に最適ですが、実際に測定したいものを見失うことはありません。
プロファイラーは、パフォーマンスの問題の診断と修正に役立つ詳細情報を提供します。
実際の測定では、ストップウォッチ時間はユーザーが気付くものであるため、許容範囲内にあることを検証する場合は、ストップウォッチ時間で十分です。
ただし、実際に問題を修正したい場合は、プロファイラーが非常に役立ちます。
タイミングをテストする方法に応じて異なる答えが得られるため、現実的な反復回数をテストする必要があります。操作を1回だけ実行する場合、多くの反復の平均を取ることは誤解を招く可能性があります。 JVMがウォームアップした後の所要時間を知りたい場合は、タイミングに含まれていない多くの（たとえば、10,000）反復を実行することができます。
また、はるかに正確であるため、System.nanoTime()を使用することをお勧めします。テスト時間が約10マイクロ秒以下の場合は、これを頻繁に呼び出さないでください。そうしないと、結果が変わる可能性があります。 （たとえば、たとえば5秒間テストしていて、これがいつアップするかを知りたい場合、反復が非常に速いことがわかっている場合は、1000回の反復ごとにのみnanoTimeを取得します）
プロファイラーはタイミングの邪魔になる可能性があるため、ストップウォッチタイミングの組み合わせを使用して全体的なパフォーマンスの問題を特定し、プロファイラーを使用して時間が費やされている場所を特定します。必要に応じてこのプロセスを繰り返します。
ベンチマーク時にオペレーティングシステムのスケジューリングにどのように対処しますか？
使用するマシンを代表するシステムでの十分な長さのベンチマーク。 OSがアプリケーションの速度を低下させる場合は、それが結果の一部になるはずです。
私がOSを持っていなければ、私のプログラムはもっと速くなると言っても意味がありません。
Linuxを使用している場合は、numactl、chrt、tasksetなどのツールを使用して、CPUの使用方法とスケジューリングを制御できます。
重要な問題は、操作の複雑さと時間の長さだと思います。
物理的なストップウォッチ測定を使用して、計算に数分、数時間、数日、さらには数週間かかるかどうかを確認することもあります（数秒と数分であっても、数日のオーダーの実行時間が前例のないアプリケーションで作業しています最も一般的な期間）。
ただし、リンク先の記事で言及されているJavaミリ秒の呼び出しなど、コンピューター上のあらゆる種類のクロックシステムの呼び出しによって提供される自動化は、何かが実行されている時間を手動で確認するよりも明らかに優れています。
プロファイラーは機能するときは素晴らしいですが、アプリケーションに適用する際に問題が発生しました。これには通常、動的コード生成、DLLの動的ロード、および2つの組み込みのジャストインタイムコンパイル済みスクリプト言語で実行される作業が含まれます。私のアプリケーション。多くの場合、単一のソース言語を想定することや、複雑なソフトウェアに対するその他の非現実的な期待に限定されています。
私は今日、一連のdBaseファイルを検索して情報を収集するプログラムを実行しましたが、実行には1時間以上かかりました。私はコードを見て、ボトルネックが何であるかを知識に基づいて推測し、アルゴリズムを少し改善し、プログラムを再実行しました。今回は2.5分で完了しました。
新しいバージョンが大幅に改善されたことを伝えるために、特別なプロファイリングツールやベンチマークスイートは必要ありませんでした。実行時間をさらに最適化する必要がある場合は、おそらくより高度な分析を行う必要がありますが、これは必要ありませんでした。この種の「ストップウォッチベンチマーク」は、かなりの数のケースで許容できるソリューションであり、これらのケースでは、より高度なツールに頼る方が実際には時間がかかることがわかりました。
結局のところ、これはおそらく「監視なしのベンチマーク」の直後に2番目に人気のあるベンチマークの形式です。「このアクティビティは遅いようですが、速いようです」と言います。
通常、最適化するのに最も重要なのは、ユーザーエクスペリエンスを妨げるものです。これは、ほとんどの場合、アクションを実行する頻度と、同時に行われていることの関数です。他の形式のベンチマークは、多くの場合、これらに焦点を合わせるのに役立ちます。
ストップウォッチのベンチマークはとても簡単なので、いつも使っています。しかし、結果は私にとって非常に正確である必要はありません。正確な結果が必要な場合は、ストップウォッチベンチマークを使用しないでください。
ストップウォッチのベンチマークはそれほどひどいものではないと思いますが、SolarisまたはOS Xマシンにアクセスできる場合は、DTraceを確認する必要があります。これを使用して、アプリケーションのタイミングに関する優れた情報を取得しました。
私はいつもそれをします。私はむしろプロファイラーを使用したいのですが、私が使用しているドメイン固有言語のベンダーはプロファイラーを提供していません。