分析到这里,让我们看看createParser() 方法的执行细节。
通过方法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工具的能力,有一套的教程和用户手册在这里。