- 為診斷出的性能問題定義一個解決方案
通過分析以上這些數據，我們發現改進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工具的能力，有一套的教程和用戶手冊在這里。
