分析性能瓶頸
可以使用 Execution Statistics 視圖來分析程序中各個方法的運行時間。打開該視圖的方式是，數據收集進程上點右鍵，選擇以 Execution Statistics 方式打開。
在該視圖中，顯示了所有調用到的方法及其運行時間。運行時間有多種表示方法。常用到的是“cumulative time”。該時間表示了這個方法調用的總耗時，其中包含其調用其他方法的時間。
我們 MyShop 插件的運行結果如上圖所示。可以看到，getProductDir 方法耗時長。而該方法的作用是打開一個文件選擇對話框，等待用戶的選擇，等選擇完成后再關閉對話框。因此其時中包含了等待用戶選擇的部分。這當然應該在 我們的性能分析中排除在外。除此之外耗費時間長的是 parseContent 方法。該方法用于從包含產品信息的 XML 文件中獲取真正的產品信息數據。雙擊該方法查看該方法調用的詳細數據。
需要注意的是，在下面的 Selected method invokes 表格中，顯示結果是通過我們設置的過濾器過濾后的結果。在上面的結果中，我們可以看到，我們自己的方法調用花費的時間都很小。由此可見，消耗時間更多的地方是在 XML 解析的方法中。
解決性能問題并驗證修改
通過對上面運行數據的分析，我們的結論是，對性能影響大的是 XML 的解析。而根據得到的數據，24 條商品數據的獲取已經需要 0.5s 的時間，而在正常使用中的商品數量則會達到根本不可忍受的程度。通過對代碼的分析，我們得知目前的 XML 解析使用的是 DOM 的分析方
式，而在我們的應用中只有 XML 的讀操作而沒有寫操作。在這種方式下，SAX 的解析方式效率要更高。因此我們可以將 XML 解析部分的代碼改為 SAX 方式。
創建 ProductSAXParser 類
創建該類實現我們的 ProductParser 接口并繼承自 DefaultHandler 接口完成大部分的分析邏輯。
實現 Parser 方法
實現 ProductParser 接口和 DefaultHandler 定義的方法完成解析邏輯。
更改 XML 解析方式
在父類 ShopView 中更改調用的解析器為我們新創建的 SAX 實現。
具體的代碼可參考本文附件所帶的示例代碼。
修改好代碼并按照上面的步驟從新運行數據分析，可以看到，現在的性能已經大為改觀：
可以看到，XML 解析方法的運行時間已經由 0.5s 左右縮短到了大約 0.057s。
