如果調用棧是如下執行的：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() 方法的執行細節。
