通过方法createParser() 打开Method Invocation Details 视图

    　下面我们通过Method Invocation Details 视图来看看createParser() 调用慢的原因。在Execution Statistics视图中双击createParser() 方法可以打开Method Invocation Details 视图，如下所示：

    　上图中显示了方法createParser()的执行信息，像你看到的一样，该方法被readData(java.lang.String)调用了一次，同时它调用了5个不同的方法，在invoked methods 表中，你能看见newSAXParser() 和newInstance() 方法可能是createParser()方法执行慢的原因，这两个方法跟createParser()被调用24次一样，也被执行了24次。

    　为诊断出的性能问题定义一个解决方案

    　通过分析以上这些数据，我们发现改进createParser()执行时间的一个途径是改进SAXParserFactory的两个方法的执行，既然我们无法控制这些方法的实现，的途径是减少调用这些方法的次数。

    　解决方案是创建一个parser实例，并且复用其去解析所有的xml文件，取代原来每解析一个文件创建一个parser实例的做法。让我们打开源代码并且修复它。

    　提示：在进行任何之类优化之前，要确保被代码支持。例如，当SAXParser不能同时被多线程使用时，实例能被复用；严格来将，实例在复用之前应该被重置（reset），拥有一套全面的单元测试集来检验这些修改是个不错的主意。

    　在源代码中应用性能优化

    　可以在Method Invocation Details视图中右键-->Open Source来打开源代码。源代码如下图：

　　上图中显示了createParser()方法的源代码。注意该方法每次调用都创建一个新的SAX parser 。更新代码，只创建一个parser实例，复用于解析每个xml文件，如下图所示：

    　正如在上图中描述的，定义了一个全局的SAXParser 实例变量parser，createParser()方法初始化parser然后在每次被调用时返回该实例。

让我们再次执行一下Product catalog程序，验证修复的结果。

    　验证性能优化

    　在Java透视图中选择Product类，右键--->Profile As -->Java Application，程序执行完后，打开Execution Statistics 视图，比较执行时间，下图所示的是做了性能优化后的结果：

        正如你看到的，createParser()方法的执行时间已经仅有19%，而在优化执行却是将近 43%。注意，随着xml文件数量的增加，提升的值将更加明显，所以，随着product文件的增加而减少的程序执行时间将是指数级的。

总结：

        本文论述了TPTP性能测试工具能被用于分析和解决性能问题，本文没有涉及TPTP工具更多的其他使用方面，如果你想了解更多的关于TPTP工具的能力，有一套的教程和用户手册在这里。

后记：

        这是自己第一次不是为了自己而翻译e文，觉得真是够累的。因此，不由得向经常翻译e文的前辈、大师们致敬！

        关于profiling的翻译：有的地方可能翻译成概要分析更好