2009-07-07 20 views
5
私は、Mac OS X(10.5.7は、Apple JDK 1.6.0_06-b06-57)の下で実行されている数学を多用するアプリケーションをプロファイルするYourkit 8.0を使用している、といくつかの奇妙なことに気づいてい

CPUプロファイリング結果の動作例えばプロファイリングネイティブメソッド - 奇妙な結果

- 私は、アプリケーションの10分の実行時間の40%がStrictMath.atanメソッドに費やされたことを報告したサンプリングを使用して、プロファイリング実行をしました。私はこの困惑を見つけましたが、私はそれを語り、atanを非常に単純な多項式に置き換えて少し時間を費やしました。私は再度アプリケーションを実行したとき

、それは(10分)前とほとんど同じ時間がかかった - しかし、私のATANの交換は、プロファイリング結果にどこまで認められませんでした。代わりに、他の主要なホットスポットのランタイムパーセンテージは単にそれを補うために増加しました。 StrictMath.atan WITH

結果(ネイティブメソッド)
総ランタイム:10分
方法1:20%
方法2:20%
方法3:20%
を要約する

StrictMath.atan:40%
合計ランタイムATAN単純化し、純粋なJavaのWITH

結果:10ありませんTES
方法1:33%
方法2:33%
方法3:33%

(メソッド1,2,3のいずれかのATAN呼び出しを実行しないでください)

何であるか任意のアイデアこのような振る舞いで?私はEJ-TechnologiesのJProfilerを使って同じ結果を得ました。 JDKプロファイリングAPIは、少なくともOS Xのネイティブメソッドでは不正確な結果を報告するようです。

+0

メソッドが呼び出される代わりに、atanがイントリンシックであれば驚くことはありません。 –

+0

私はMac OS X 10.7(およびそれ以前のバージョンも)のStrictMathのさまざまなメソッドでこれを経験しました。 –

+0

この問題の解決方法はありますか? – ziggystar

答えて

3

これは、サンプルをとったときの不一致のために起こります。たとえば、メソッドがかなりの時間を使用するが、実行にそれほど時間がかからない場合、サンプリングがそれを見逃す可能性があります。また、ガベージコレクションはサンプル中では起こりませんが、コードによってはガベージコレクションが多く発生すると、サンプルに表示されずに減速に大きく貢献する可能性があります。

同様の状況で、2回、1回のトレースと1回のサンプリングで実行すると非常に便利です。メソッドが両方に表示されているのであれば、CPUを多用している可能性があります。それ以外の場合は、単にサンプリングプロセスの成果物になる可能性があります。

0

私はあなたのキットがサブメソッドを呼び出すコストを大幅に誇張していることを発見しました。プロファイルが与えるアドバイスに従うだけでHotSpotが通常これをうまく実行するので、実際の利得を持たない関数をマージすることになります。

したがって、私は非常に変更が本当に有益であるかどうか、より良いアイデアを得るために、あまりにもバッチに完全に外プロファイラをテストするためにお勧めする(それは明白に見えるかもしれませんが、これは私にいくつかの開発時間を要しました)。

0

Macを使用しているので、あなたはJavaサポートを持っており、Appleのパフォーマンスグループは、ツールにかなりの時間を入れているApple's Shark profiler(ADCから無料でダウンロード)を試してみてください。

Nickが指摘しているように、サンプル間隔が関数の実行時間に十分に近く、関数が実際に実行されているときにプロファイラがほとんど確認しないと、サンプリングが誤解を招く可能性があります。私はYourKitがこれをサポートしているかどうか分かりませんが、Sharkではサンプリング間隔をデフォルトの10ms以外のものに変更して、結果が大きく異なるかどうかを確認できます。 また、すべての関数の入力/戻りを記録する別のコールトレースモードもあります。エイリアシングエラーの可能性は完全に排除されますが、大量のデータとオーバーヘッドが発生します。処理。

0

3つのメソッドに渡されるパラメータを調べることができます。戻り値の生成に費やされている時間や、多数の一時オブジェクトを作成しているメソッドで時間が費やされている可能性があります。

-1

プロファイラーはそのようにすることができます。

This is the method I use.

たびに動作します。

And this is why.

+0

これが、このプロセスを自動化するサンプリングプロファイラの結果と異なる結果をもたらす理由を説明したいと思いますか? – ziggystar

+0

@ziggystar:いくつかのサンプリングプロファイラは、ウォールクロック(CPUではなく)時間に、スタック全体をサンプリングするプロセスの半分を自動化します。自動化しないプロセスの半分は、修正可能なパフォーマンス上の問題の発見です。ステートメントや関数のインクルーシブ%が小さい場合は、他の場所に問題がありますが、問題が非常に深いところで絞り込まれません。単にコード、関数、または "パス"の行が "ホット"であることを知っているだけでは、それほど多くは分かりません。特定の代表サンプルを完全に調べることができれば、より明らかになります。 ... –

+0

@ziggystar:...これがもたらす別の結果は、非常に良いプロファイラでも見つからないスピードアップを見つけることです。これらの問題を修正してプロセスを繰り返すと、プログラムの時間が短縮されるため、以前の小さな問題は大きくなりました。だから、一つ一つ、あなたはこれらを修正し、複合化されたスピードアップは驚くべきことです。プロファイラでどれくらいスピードアップしましたか?答えが40%を超える場合は、私を驚かせるだろう。 –

0

また、彼らは十分に小さい場合には、Javaメソッドがしかし、ネイティブメソッドが異なるルールの下でインライン化され、インライン化できることは注目に値します。メソッドがインライン化されていれば、それはプロファイラには表示されません(確かにYourKitではありません)