通過方法createParser() 打開Method Invocation Details 視圖
下面我們通過Method Invocation Details 視圖來看看createParser() 調用慢的原因。在Execution Statistics視圖中雙擊createParser() 方法可以打開Method Invocation Details 視圖，如下所示：
上圖中顯示了方法createParser()的執(zhí)行信息，像你看到的一樣，該方法被readData(java.lang.String)調用了一次，同時它調用了5個不同的方法，在invoked methods 表中，你能看見newSAXParser() 和newInstance() 方法可能是createParser()方法執(zhí)行慢的原因，這兩個方法跟createParser()被調用24次一樣，也被執(zhí)行了24次。
為診斷出的性能問題定義一個解決方案
通過分析以上這些數(shù)據(jù)，我們發(fā)現(xiàn)改進createParser()執(zhí)行時間的一個途徑是改進SAXParserFactory的兩個方法的執(zhí)行，既然我們無法控制這些方法的實現(xiàn)，的途徑是減少調用這些方法的次數(shù)。
解決方案是創(chuàng)建一個parser實例，并且復用其去解析所有的xml文件，取代原來每解析一個文件創(chuàng)建一個parser實例的做法。讓我們打開源代碼并且修復它。
提示：在進行任何之類優(yōu)化之前，要確保被代碼支持。例如，當SAXParser不能同時被多線程使用時，實例能被復用；嚴格來將，實例在復用之前應該被重置（reset），擁有一套全面的單元測試集來檢驗這些修改是個不錯的主意。
在源代碼中應用性能優(yōu)化
可以在Method Invocation Details視圖中右鍵-->Open Source來打開源代碼。源代碼如下圖：
上圖中顯示了createParser()方法的源代碼。注意該方法每次調用都創(chuàng)建一個新的SAX parser 。更新代碼，只創(chuàng)建一個parser實例，復用于解析每個xml文件，如下圖所示：
正如在上圖中描述的，定義了一個全局的SAXParser 實例變量parser，createParser()方法初始化parser然后在每次被調用時返回該實例。
讓我們再次執(zhí)行一下Product catalog程序，驗證修復的結果。
驗證性能優(yōu)化
在Java透視圖中選擇Product類，右鍵--->Profile As -->Java Application，程序執(zhí)行完后，打開Execution Statistics 視圖，比較執(zhí)行時間，下圖所示的是做了性能優(yōu)化后的結果：
正如你看到的，createParser()方法的執(zhí)行時間已經(jīng)僅有19%，而在優(yōu)化執(zhí)行卻是將近 43%。注意，隨著xml文件數(shù)量的增加，提升的值將更加明顯，所以，隨著product文件的增加而減少的程序執(zhí)行時間將是指數(shù)級的。
總結：
本文論述了TPTP性能測試工具能被用于分析和解決性能問題，本文沒有涉及TPTP工具更多的其他使用方面，如果你想了解更多的關于TPTP工具的能力，有一套的教程和用戶手冊在這里。
后記：
這是自己第一次不是為了自己而翻譯e文，覺得真是夠累的。因此，不由得向經(jīng)常翻譯e文的前輩、大師們致敬！
關于profiling的翻譯：有的地方可能翻譯成概要分析更好
