次の節では、プロファイラから提供される結果を評価する際に考慮すべき情報について説明します。
ルートノードのセルフタイム統計を計算する場合、プロファイラは、ルートノードの合計時間からすべての子ノードの時間を減算します。
したがって、計測されていない子ノードの時間がルートノードのセルフタイムに反映されます。ルートノードのセルフタイムがかなり多い場合は、その理由を必ず調査するようにしてください。適切なメソッドで計測していないために、間違った場所を見ている可能性もあります。
たとえば、メソッド A がメソッド B を呼び出すとします。
メソッド A に合計 10 秒 (この合計時間には B の呼び出しも含まれる)、B の呼び出しに合計 10 秒がかかっています。
A と B の両方を計測していれば、呼び出しスタックにその情報が反映されます。A のセルフタイムは 0 秒、B のセルフタイムは 10 秒と表示されます (10 秒は実際に B で消費された時間)。これに対し、B を計測していない場合は、A の呼び出しに 10 秒かかり、A のセルフタイムは 10 秒であると表示されます。したがって、B ではなく A に直接問題があると考える可能性があります。
特に、最初のコンパイルで JSP のセルフタイムが多いことに気づく場合があります。収集された結果をリセットしてからページを再表示すると、セルフタイムの値はかなり少なくなります。
Java の計測方針には制限があるため、this() または super() の最初の呼び出しは、コンストラクタ呼び出しの子としてではなく兄弟として表示されます。次の例を参照してください。
class A { public A() { this(0); } public A(int i) { } } and: class B { public static void test() { new A(); } } The call tree will look like this: B.test() -A.<init>(int) -A.<init>() Rather than this: B.test() -A.<init>() -A.<init>(int) |
ReconTask.WorkerThread.run() や TaskThread.WorkerThread.run() など、Identity Manager のいくつかのデーモンスレッドで大量の時間が消費されたように見えますが、これに惑わされないでください。この時間の大部分は、イベントを待機しているスリープ中に消費されたものです。イベントの処理中に実際に消費された時間を確認するには、これらのトレースを調査する必要があります。