摘要:找出「程式碼的效能瓶頸」- VSTS 2008 的效能分析 ( Profiling )
相信程式人員大部分對這個功能都沒有什麼概念或是沒有聽過，前陣子都是聽到 Refactorying , Unit Test , 程式碼自動分析 , 自動化測試啦…
效能分析相較之下就顯得比較沒有人氣了，導致這麼好用的一個功能就被大家遣忘了。 (至少我覺得這應該是每個程式人員都要用的)
它主要就是幫程式人員找出「程式碼的效能瓶頸」，而且，用此工具的門檻也是最低的。
為什麼呢？？因為像
- Test Drvien 的 Unit Test ，先決條件是程式碼必須是有物件導向的寫法。
- 程式碼維護度分析，當然這也是程式碼有物件導向時才會有最棒的效果。
- 程式碼自動分析 (Code Review)， 這個工具也很簡單，但比較有障礙的應該是程式人員自已吧！ XDD 大部分的程式人員都有一定程度的潔癖，一開始大部分都沒有辦法忍受「錯誤清單」中有一堆 黃色的小三角形。 ( PS.. 現在自已在寫程式時，都會開這個功能了 很方便，以後會提到 )
以前在寫程式時最痛苦的就是，某一天使用者 ( or 測試人員) 說「怎麼某某某個地方程式特別慢呀！」，聽到這個總是一臉晴天霹靂樣。Orz
簡單的可能用「目測」就可能找出來了，但通常事情沒那麼好過， Method 一個呼叫一個 ，Class 一層包一層。 壓根不知道是那一個地方慢
唉~~~ 這時只好使出「土法練鋼」大法，在每一個 Method 的最前面和最後面加上 Time Start 和 Time End 來記錄程式執行所花費的時間，光是這個就可能花了我二天的時間 ( 通常都不止啦！因為專案都超大的) 。最後當然還要輸出成 Log 檔以方便用人的眼精確認嚕！
寫好了程式碼後，就會再重複執行一次次的程式，然後反覆查核產出超多的 log 檔，光看到裡面有上千條的 Log 應該都暈了吧。然後還是不知道到底是那一段的程式碼在慢 ( 而且不是要改善效能嗎？寫越多的 Log ，程式的效能就越慢 )
然後一段無止盡的找效能地獄就會無窮迴圈地下去~~~~~~ ( 連做夢都會夢到 )
情況好一點的可能幾天就解脫了，普通的可能一兩週，最慘的可能連離職時都還找不出原因。
最後，好不容易找到也修改好效能問題後，還要再把之前寫的 Time Start 、Time end 和 Log 的相關程式都要還把它們全部拿掉。這無疑又是一次慘痛的打擊。
============= 我是分隔線 ==========================================================
現在在 VS 2008 中有 效能分析 ( Profiling ) ，就可以解脫我們這些 寫程式的普羅大眾啦！！
可以少做什麼？？
- 不用再寫笨死的 Time Start , Time End
- 也不用寫 會讓效能低落的 Log (一直存取 IO 當然會變得更慢啦 )
- 不用自已去分析 Log (看完都天亮了 )
- 測試人員可以協助產生 Report
說了這麼多 來看看怎麼做吧！
開啟專案後，檢視-->其他視窗-->「效能總管」
出現效能總管 ，點選「新增效能工作階段」
1. 按下新增
2. 便會產生 Performance1
3. 在目標按下右鍵加入目標專案
4. 選取欲檢測效能的專案檔
注意：一定要有「起始專案」，但只能有一個。
Ex.. WebAP / Windows AP
5. 按下確定
6. 點選 Petshop Web AP
7. 按下「啟動並啟用程式碼剖析」
在 VM 中的話只能用「檢測」
8. Web AP 會開啟 IE (Windows AP 則會直接啟動應用程式)
9. 進行功能執行
若是元件有註冊到 GAC 的話！會出現以下的對話框， 可以不用理它 。
這時候好處就來了！！ 可以依照使用者所說的「操作步驟」去找系統是不是真的有效能上的問題。這時候就可以注意到了完全沒有任何看程式碼的問題，所以連非程式人員都可以很容易協助找出效能問題。唉呀！！想到就覺得開心多了不用自已再一個一個去執行。又多了一個理由可以讓別人幫忙找效能問題 :)
10. 關閉 ie
11. 產生報表
由精靈幫我們分析所有的資訊也是很重要的，至少不用再自已一行一行去看 Log 啦！！就有一堆統計的資料，還有幫我們排名花費的時間。
以前我們只能知道「自已寫的程式碼」效能，卻不知道 Framework 到底花了多少時間。現在連這些資訊都可以掌控一清二楚
我們就可以知道那些的 API 要盡量少呼叫，或是修改呼叫的方式。 ( Ex.. String 和 StringBuild )
「最常呼叫的函式」代表這些的 Method 被呼叫的次數最多
「含有最多個別工作的函式」代表 一個 Method 裡有多個 Method 的排名和花費時間
「費時最長的函式」代表一個 Method 花費時間的排名
當然也可以由精靈列出那一個最慢
樹狀分析
只有在此模式才會有「火球」的圖案，讓我們可以馬上知道那一個最慢。
模組分析 = 列出所有被執行過的 (有排序過)
============= 我是分隔線 ==========================================================
當然找到問題後，最重要的是把效能問題解決。
以往我們最擔心的是！程式怎麼越改越慢 ~~~ 天啊！！已經很火燒屁股了怎麼還發生這種事情。
為了避免發生剛剛講的情況，要如何知道程式效能是真的被改好的，也是用這個工具！！
修改好程式碼後，再執行上面的流程整個跑一篇。這時也還會再產出一個新的「Report」
用Ctrl 把兩個報表都選取後，按右鍵選「比較效能報告」
就可以列出程式修改後程式效能是否確實提升。
( 重要：兩次的執行方式必須要盡量一致，數據才會符合 。)
所以，就連修改前、修改後的效能都會有數據。
從這裡就可以看到，不用很複雜的做法，也完全不用寫任何一行程式碼，就可以把所有執行過的資訊匯整成報表，並且有很多種不同量化的數據。這樣子就真的可以省下很多時間，可以早點下班回家。 啊~ 是專注在更重要的地方上。