通過方法createParser() 打開Method Invocation Details 視圖

    　下面我們通過Method Invocation Details 視圖來看看createParser() 調(diào)用慢的原因。在Execution Statistics視圖中雙擊createParser() 方法可以打開Method Invocation Details 視圖，如下所示：

    　上圖中顯示了方法createParser()的執(zhí)行信息，像你看到的一樣，該方法被readData(java.lang.String)調(diào)用了一次，同時(shí)它調(diào)用了5個(gè)不同的方法，在invoked methods 表中，你能看見newSAXParser() 和newInstance() 方法可能是createParser()方法執(zhí)行慢的原因，這兩個(gè)方法跟createParser()被調(diào)用24次一樣，也被執(zhí)行了24次。

    　為診斷出的性能問題定義一個(gè)解決方案

    　通過分析以上這些數(shù)據(jù)，我們發(fā)現(xiàn)改進(jìn)createParser()執(zhí)行時(shí)間的一個(gè)途徑是改進(jìn)SAXParserFactory的兩個(gè)方法的執(zhí)行，既然我們無法控制這些方法的實(shí)現(xiàn)，的途徑是減少調(diào)用這些方法的次數(shù)。

    　解決方案是創(chuàng)建一個(gè)parser實(shí)例，并且復(fù)用其去解析所有的xml文件，取代原來每解析一個(gè)文件創(chuàng)建一個(gè)parser實(shí)例的做法。讓我們打開源代碼并且修復(fù)它。

    　提示：在進(jìn)行任何之類優(yōu)化之前，要確保被代碼支持。例如，當(dāng)SAXParser不能同時(shí)被多線程使用時(shí)，實(shí)例能被復(fù)用；嚴(yán)格來將，實(shí)例在復(fù)用之前應(yīng)該被重置（reset），擁有一套全面的單元測(cè)試集來檢驗(yàn)這些修改是個(gè)不錯(cuò)的主意。

    　在源代碼中應(yīng)用性能優(yōu)化

    　可以在Method Invocation Details視圖中右鍵-->Open Source來打開源代碼。源代碼如下圖：

　　上圖中顯示了createParser()方法的源代碼。注意該方法每次調(diào)用都創(chuàng)建一個(gè)新的SAX parser 。更新代碼，只創(chuàng)建一個(gè)parser實(shí)例，復(fù)用于解析每個(gè)xml文件，如下圖所示：

    　正如在上圖中描述的，定義了一個(gè)全局的SAXParser 實(shí)例變量parser，createParser()方法初始化parser然后在每次被調(diào)用時(shí)返回該實(shí)例。

讓我們?cè)俅螆?zhí)行一下Product catalog程序，驗(yàn)證修復(fù)的結(jié)果。

    　驗(yàn)證性能優(yōu)化

    　在Java透視圖中選擇Product類，右鍵--->Profile As -->Java Application，程序執(zhí)行完后，打開Execution Statistics 視圖，比較執(zhí)行時(shí)間，下圖所示的是做了性能優(yōu)化后的結(jié)果：

        正如你看到的，createParser()方法的執(zhí)行時(shí)間已經(jīng)僅有19%，而在優(yōu)化執(zhí)行卻是將近 43%。注意，隨著xml文件數(shù)量的增加，提升的值將更加明顯，所以，隨著product文件的增加而減少的程序執(zhí)行時(shí)間將是指數(shù)級(jí)的。

總結(jié)：

        本文論述了TPTP性能測(cè)試工具能被用于分析和解決性能問題，本文沒有涉及TPTP工具更多的其他使用方面，如果你想了解更多的關(guān)于TPTP工具的能力，有一套的教程和用戶手冊(cè)在這里。

后記：

        這是自己第一次不是為了自己而翻譯e文，覺得真是夠累的。因此，不由得向經(jīng)常翻譯e文的前輩、大師們致敬！

        關(guān)于profiling的翻譯：有的地方可能翻譯成概要分析更好