如果調用棧是如下執行的:MyMethod>M1>M2>M3>M4,基于在2a中設置的過濾條件,性能解析器將顯示如下的調用棧:MyMethod>M1>M2>M3,將不顯示后一級調用M3>M4(因為超過了3層)。如下圖所示
3.選擇要剖析的類
在Moniter頁中,選擇Java Profiling項,然后雙擊或者單擊編輯按鈕,打開The Filter Set 向導。利用The Filter Set 界面來選擇你想剖析的類,這里已經預先定義了一組可用的過濾器,本例來說,你可以通過下面幾步創建一個新的過濾器:
3a)單擊Add..按鈕,在彈出的對話框中輸入ProductFilterSet,然后單擊OK。
3b)使用Contents of selected filter set列表中的Add按鈕增加兩個過濾器,如下圖所示:
運行程序
可以通過在Launch Configuration wizard向導中點擊OK按鈕來運行Product catalog 程序,在詢問是否切換到Profiling and Logging透視圖時選擇Yes,你將在Console視圖中看到如下圖所示的結果:
提示:TPTP性能測試工具允許你和你所剖析的程序之間交互。你能暫停、恢復監聽,運行垃圾收集回收對象引用或者中止程序的運行。
使用Execution Statistics視圖分析性能危險點
使用Execution Statistics視圖去分析性能危險點,在Profiling Monitor視圖中,右鍵-->Open with > Execution Statistics可以打開Execution Statistics視圖,下圖顯示的是按照方法調用的累積時間排序的,累積時間是指該方法花費的所有時間,包含調用其他方法的消耗的時間。
正如上圖所示,Execution Statistics 顯示在上方的方法:main(java.lang.String[]), readData(java.lang.String) 和createParser() 消耗了多的執行時間。看見main和readData方法在列表中(的位置)是不奇怪的,因為前者是程序執行的開始點,后者從其名字可以看出它從xml文件中讀取產品信息。
使我們覺得奇怪的是方法createParser() ,它僅僅創建了用于解析xml文件的SAX parser 實例花費了如此高的執行時間。該方法的執行時間占了整個應用的執行時間的42.96%,Execution Statistics 幫助我們分析這個方法是性能優化的潛在的地方。
分析到這里,讓我們看看createParser() 方法的執行細節。