NetBeans Profiler 5.5 の使用方法
計測の枠組み
すべてのメソッドではなく、アプリケーションコードの限定された一部を計測することによって、プロファイルのオーバーヘッドを大幅に軽減することができます。サーバーサイドのアプリケーションなど、実行時間が長く、まったく同じか類似の処理を繰り返し実行するアプリケーションをプロファイルする場合に推奨される手法は、1 つまたは複数の root メソッドを選択し、それらの呼び出しの部分グラフを計測することです。しかし、アプリケーションの起動や実行時間が短いコマンド行アプリケーションをプロファイルする場合は、アプリケーションコードの大部分またはすべてを計測する方が効率的な場合があります。
計測するメソッドの順番や計測するメソッドのおよその数を判断するために、Profiler には「少なく」、「合計」、「多く」の 3 つの計測の枠組みが用意されています。
-
計測の枠組み:「少なく」
これは、「プロファイルタスクの選択」ダイアログの「パフォーマンスを解析」で、「アプリケーションの一部」を選択したときに使用されるデフォルトの枠組みです。実行時間の長いアプリケーションに最適です。この枠組みが使用されたとき、Profiler は次のようにメソッドを計測します。最初に root メソッドが計測され、次に、きわめて早い段階でメソッド (このメソッドを
m()とします) が実行されるたびに、m() のコードが走査され、m()呼び出すであろうすべてのメソッドが計測されます。この方法により、計測されるメソッドの数はターゲットアプリケーションの実行中に呼び出されるメソッドの数に近くなります。root メソッドから呼び出されないメソッドについて、計測されるメソッドの数を最小にすることによって、計測時間を短縮しています。計測されたメソッドが root メソッドから実際には呼び出されず、プログラムのほかの部分から呼び出される場合に発生する可能性のあるオーバーヘッドも回避されます。
それでも、計測するメソッド数は、通常、実際に呼び出されるメソッド数より大きくなります。一番の理由は、平均的な Java アプリケーションでは多くのメソッドが仮想的なもの (つまりstaticでない) ためです。そのため、ソースコードに、x.m()のような呼び出しがあり、変数xの型がXである場合、Profiler はX.m()メソッドだけではなく、Xのサブクラス内のメソッドm()のすべての実装も計測する必要があります。xが実際にどのクラスになるのかを実行時に知ることは一般的に不可能であり (実際、何回も変わる可能性がある)、そのため、m()の具体的などの実装が呼び出されるかを知ることができないためです。
「少なく」という計測の枠組みは、長時間実行されるアプリケーションのプロファイルに最適ですが、多くのクラスが読み込まれる間や、単純な計測が行われている間にアプリケーションのプロファイルを行う必要がある場合には、あまりうまく機能しないことがあります。Profiler が使用する HotSpot JVM では、パフォーマンスの向上のため、通常多くのアプリケーションメソッドがマシンコードにコンパイルされるため、このようなことが起こります。メソッドとがコンパイル後に計測される場合には、JVM は、まず始めにバイトコードの解釈に戻ります (そのあと、このメソッドは再びコンパイルされる可能性がある)。バイトコードの解釈への一時的な切り替わりは、そのメソッド自体は計測対象ではない、計測されるメソッドを呼び出すメソッドに対しても行われることがあります。このため、Profiler が呼び出しグラフを検出している間と、そのあとしばらくの間、アプリケーションの実行時間がかなり遅くなることがあります。この期間の CPU プロファイル結果は通常の実行を反映していません。呼び出しグラフの計測後しばらくの間アプリケーションを実行させて (サーバーサイドアプリケーションの場合、数百または数千の要求を処理させるなど)、そのあとに、「Profiler コントロールパネル」で「プロファイル」->「収集結果をリセット」ボタン (
) をクリックし、すでに収集されたプロファイル結果をいったん削除することを推奨します。そのあとで収集されるプロファイル結果は、はるかに実態に即したものになります。 計測の枠組み:「合計」
この枠組みは、定義済みのプロファイルタスク「パフォーマンスを解析」で、「アプリケーション全体」を選択したときに使用されます。この枠組みを選択すると、Profiler はほかの大部分のプロファイルと同じように機能します。つまり、ターゲットアプリケーションのすべてのメソッドを、それらのメソッドを含むクラスが呼び出されるとただちに計測します。この枠組みは、長時間実行されるアプリケーションではオーバーヘッドが著しく増大する可能性がありますが、アプリケーションの起動時のプロファイルや、コマンド行ユーティリティーなどの比較的小さな実行時間の短いアプリケーションのプロファイルで使用した場合に、結果が正確で、オーバーヘッドがかえって小さくなることもあります。これは、上記の計測の枠組み「少なく」で説明した、メソッドのデコンパイルとリコンパイルの繰り返しの問題が発生しないためです。
-
計測の枠組み:「多く」
「多く」という枠組みは、上記の 2 つの枠組みの折衷策です。「少なく」とはことなり「多く」という枠組みでは、クラスが読み込まれるとただちに、クラス内の到達する可能性のあるすべてのメソッド (つまり、root メソッドから直接または過渡的に呼び出される可能性のあるメソッド) を見つけます。到達可能性をより多く分析することによって、呼び出されるメソッド数よりも多くのメソッドが計測される可能性があります (10 倍多い場合もある)。このため、この枠組みを長時間実行されるアプリケーションに使用することは推奨されません。しかし、メソッドのデコンパイルとリコンパイルの繰り返しの数ははるかに少なくなるため、たとえば、アプリケーションの起動時に発生する処理をプロファイルする場合や、「合計」を使用した計測のオーバーヘッドが大きすぎるように見える場合に、有効なことがあります。
関連項目
