統計注意事項

以下各節包含計算效能評測器提供結果時所要考量的資訊：

• Self Time 統計

• 建構子呼叫

• 常駐程式執行緒

Self Time 統計

若要計算根節點的 Self Time 統計，效能評測器會從根節點的總計時間扣除所有子節點的時間。

因此，未執行的子節點時間會反映在根節點的 Self Time 中。如果根節點有很長的 Self Time，則必須找出原因。您可能尚未執行適當的方法，因此檢查的地方有誤。

例如，假設方法 A 呼叫方法 B。

方法 A 總計需要 10 秒 (其中總計時間包含呼叫 B)，而呼叫 B 總計需要 10 秒。

如果 A 與 B 皆已執行，則呼叫堆疊會反映此資訊。您會看到 A 的 Self Time 為 0 秒，而 B 的 Self Time 為 10 秒 (其中 10 秒是實際用在 B 中的時間)。但是，如果未執行 B，您僅會看到呼叫 A 需要 10 秒，因此 A 的 Self Time 為 10 秒。因此，您可能會以為問題是在 A，而不是在 B。

您尤其會在 JSP 初始編譯期間注意到 JSP 有很長的 Self Time。如果重設收集的結果，然後重新顯示頁面，則 Self Time 值會少得多。

建構子呼叫

由於 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)

常駐程式執行緒

多數 Identity Manager 的常駐程式執行緒 (例如 ReconTask.WorkerThread.run() 或 TaskThread.WorkerThread.run()) 所耗用的時間看似很久，但請勿被此誤導。大部分的時間是耗用在等候事件時的暫停上。您必須研究這些追蹤才能知道處理事件實際耗用的時間。