如果调用栈是如下执行的：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() 方法的执行细节。