用數據來證明效能問題–C++ 效能分析 Profiling
這次我們的主角是 Native C++ 效能問題
當團隊都沒有人會寫 _____ 時，又如何來管理和擔任把關的角色
( _____ 請自行更換正在管理的開發語言 )
這對於專案 owner 通常都是燙手山芋的問題
基本上就是 想丟沒辦法！要吃又吞不下去 的囧境
這時候很多人會問
就直接請開發人員或委外廠商改到好，不就得了？
但若是開發人員這個時候說「這個本來就有這個限制」「那你認為那裡有問題？」
這時能怎麼辦？沒圖沒真相就沒有辦法請別人修改啊
我們來看一下案例 用 C++ 搭配 MDAC ADO 1.5 做資料庫 1000 筆時間要 18 – 27 秒
(圖中這次執行的是 27 秒 )
到底是慢在那裡啊？有人可以告訴我嗎？ ~~~~
若是剛好用 .NET、C++ Manage Code、Native C++ 的話
我們就可以用 Visual Stuido 來告訴我們啦！ ( 其他的語言就要另外找相對應的工具了 )
開啟工具後選擇「分析」—>「執行效能精靈」 ( 這裡用的工具是 VS 11 Beta ，當然也可以用 VS 2010
若是想要了解每一個 Method 執行的次數、執行時間，所以可以用「檢測」
所以，這次我們主要會用「檢測 Instrumentation」來分析
最後會出現「效能總管」再選擇「開始分析」就會將程式啟動
CPU 效能圖表，工作項目都不超過 40% 這代表 CPU執行的部分沒有最佳化
測試的機器是 4 核心的 ( 程式當中都沒有多執行緒 )
在 Summary 中列出 那些 Method 是最慢的，可以看到 地址分析最花時間約佔整體的 45%
另外我們也會想要知道，那些 Method 或是 元件的工作量最重，可以看到這次分析後 MDAC 最花時間
從以上報表提供的資訊後，首先當然是先行確認 Hot Path 中的 Method
裡面到底執行了那些？所以我們點兩下後便會切換到 Function Details
這裡提供非常重要的資訊讓我們知道，ParseAddressInner 本身只花了不到 0.1 %
(為了避免電腦執行的差異，所有的數字都用% )
而其中 ParseCity 卻佔了 35.6% ，再上方的 ParseCity 區塊點下後
又會再切換到 ParseCity 的 Function Details
同樣這時就可以立即判斷出來，我們光是在 MDAC 執行 Excute 花費了非常多的時間
佔整體的 35.2 %
為了避免我們過於 獨斷的方式來判斷，我們將報表切換到 「Call Tree」
因為這次程式執行時約會執行 1000 次，而我們在 Call Tree 圖表中也得知
相關的 Method 所執行的次數是否有符合預期
的確相關的 method 都分別執行了 1000 次，這時我們再切換到 ParseCity 看看執行的情況
可以看出來光是 ParseCity 執行 SQL Excute 就做了 3000 次
代表每執行 一次 parse city 就分別執行 SQL Excute 三次，雖然有些時候商業邏輯上有必要
但這也是造成效能衝擊之一
當然點兩下後也是會看到 Hot Path 是那一段程式碼
為了再次證明 Excute 花費的比例造成效能衝擊，我們重新將效能總管的設定改成 CPU Sampling
同樣的程式再跑一次後就可以看到 那一行程式碼花了多少時間的比例 ( 這個只有 VS 2012 支援)
圖中很明細可以看到 Excute 這一行就佔了 17 %
這對於我們提出數據證明已經非常有效果了！因為是那一行統統都列出來了
希望這些實務問題可以讓一些有同樣問題的朋友降低你們的問題 :)