[移山之道 第九章]

9.4? VSTS 效能分析工具

啊，效能分析，Performance！這是每一個程序員都夢想的事兒，讓自己的程序跑得又快又好，最好是比別的同學快一個數(shù)量級，別人的程序是O(N^2)，而我的程序是O(n*logN)，或者是O(N)，這是多爽的一項成就呀！VSTS提供了方便的效能分析工具，讓我們能很快地找到程序的效能瓶頸，從而能有的放矢，改進程序。下面我們看一個具體的例子。

和同學們的作業(yè)類似，有這樣一道題：

寫一個程序，分析一個文本文件中各個詞出現(xiàn)的頻率，并且把頻率最高的10個詞打印出來。

?

果凍很快用C#寫好了程序，命名為WordFreq.exe，然后運行了一下，驗證了正確性，程序的基本框架如代碼清單9-3所示（全部程序可以在移山社區(qū)網(wǎng)站下載）：

代碼清單9-3? WordFreq程序，程序框架

DoIt()

{

??? ProcessFile()? //store all words in a big buffer

??? ProcessBuffer()? //calculate and store the frequency of each word

??? OutputResult()?? //output top 10

}

?

ProcessBuffer()

{

??? GetOneWord()?? //get one word from buffer

??? FreqOneWord()

}

?

FreqOneWord(word)

{

Find the word in the array list,

If (found)

??? Update the frequency

If (not found)

??? Add the word in the array list with frequency = 1

}

?

OutputResult()

{

ArrayList.Sort()?? //sort the array

Output Top 10 entry;

}

文本文件大約是30KB~300KB大小。在運行效能分析之前，阿超讓大家預計占用時間最多的是什么函數(shù)，或者哪些語句。大家眾說紛紜，有的說是處理文件，因為I/O很花時間，有的說是排序，有的說是處理每個詞。還有人建議應該把排序和處理每一個詞同時進行，這樣就能加快速度。

我們看看到底會是什么情況。第一步，要確保編譯的程序是Release版本。然后在VS界面中選中Tools | Performance Tools | Performance Wizard（如圖9-1所示）。

圖9-1? 效能分析，選擇分析方法

我們看到可以選擇兩種分析方法：

（1）??????? 抽樣（Sampling）

（2）??????? 代碼注入（Instrumentation）

通俗地解釋，抽樣就是當程序運行時，Visual Studio時不時看一看這個程序運行在哪一個函數(shù)內(nèi)，并記錄下來，程序結(jié)束后，Visual Studio就會得出一個關于程序運行時間分布的大致的印象。這種方法的優(yōu)點是不需要改動程序，運行較快，可以很快地找到瓶頸。但是不能得出精確的數(shù)據(jù)，代碼中的調(diào)用關系（CallTree）也不能準確表示。

另一方面，代碼注入就是將檢測的代碼加入到每一個函數(shù)中，這樣程序的一舉一動都被記錄在案，程序的各個效能數(shù)據(jù)都可以被精準地測量。這一方法的缺點是程序的運行時間會大大加長，還會產(chǎn)生很大的數(shù)據(jù)文件，數(shù)據(jù)分析的時間也相應增加。同時，注入的代碼也影響了程序真實的運行情況（這有點像量子物理學中的“測試的光線干擾了測試物體本身”的現(xiàn)象）。

我們一般的做法是，先用抽樣的方法找到效能瓶頸所在，然后對特定的模塊用代碼注入的方法進行詳細分析。

對程序進行效能分析，我們先要弄清下面這幾個名詞，如表9-1所示：

表9-1? 效能分析的名詞解釋

名? 詞	含? 義
調(diào)用者Caller	函數(shù)Foo()中調(diào)用了Bar()，Foo()就是調(diào)用者
被調(diào)用函數(shù)Callee	見上，Bar()就是被調(diào)用函數(shù)
調(diào)用關系樹Call Tree	從程序的Main()函數(shù)開始，調(diào)用者和被調(diào)用函數(shù)就形成了一個樹形關系——調(diào)用樹
消逝時間Elapsed Time	從用戶的角度來看程序運行所花的時間。當用戶看到一個程序沒有反應，用戶并不知道程序此時是在運行自己的代碼，還是被調(diào)度出去了，或者操作系統(tǒng)此時正在忙別的事情
應用程序時間Application Time	應用程序占用CPU的時間，不包括CPU在核心態(tài)時花費的時間

?

續(xù)表

名? 詞	含? 義
本函數(shù)時間Exclusive Time	所有在本函數(shù)花費的時間，不包括被調(diào)用者使用的時間
所有時間Inclusive Time	包含本函數(shù)和所有調(diào)用者使用的時間

理解了上面的各種概念后，我們就不難理解“消逝的本函數(shù)時間（Elapsed Exclusive Time）”等其他組合名詞所代表的概念了。

我們先進行抽樣分析，在效能瀏覽器（Performance Explorer）中開始效能分析即可。

圖9-2是WordFreq程序處理一個30KB的文本文件時的情況：

圖9-2? 用抽樣的方法分析效能

大家可以看到最花時間的三個函數(shù)是：

WordFreq.Freq.FreqOneWord(string)

System.String.EqualsHelper(string,string)

System.Collections.ArrayList.get_Item(int32)

三個函數(shù)加起來占用了整個程序84%的時間。看來我們得分析為什么這三個函數(shù)會被調(diào)用得這么頻繁，開銷這么大了。

我們現(xiàn)在可以進行代碼注入的分析，同樣運行程序后，我們看看圖9-3的調(diào)用樹（Call Tree）報告。

圖9-3? 代碼注入方法產(chǎn)生的效能報告

?

結(jié)合實際的代碼（見代碼清單9-4），可以看到在WordFreq. FreqOneWord函數(shù)中，究竟發(fā)生了什么：

代碼清單9-4? FreqOneWord()

??????? private void FreqOneWord(string w)

??????? {

??????????? // see if we have a match, if not, add it to the end,

??????????? // then assign it initial frequency 1;

??????????? // if yes, inc the frequency by 1

??????????? for (int i = 0; i < m_wordList.Count; i++)

??????????? {

??????????????? Frequency fi = (Frequency)m_wordList[i];

?

??????????????? if (fi.str == w)

??????????????? {

??????????????????? fi.n++;

??????????????????? return;

??????????????? }

??????????? }

?

??????????? //now we have to append it to the end.

??????????? Frequency f = new Frequency();

??????????? f.str = w;

??????????? f.n = 1;

??????????? m_wordList.Add(f);

??????? }

我們可以清楚地看到：

WordFreq.Freq.FreqOneWord(string)被調(diào)用了8 150次，說明有8 150個詞被處理了。但是，System.Collections.ArrayList.Add(object)被調(diào)用了1 112次，說明有1 112個不同的詞被加入到ArrayList中。下面三個函數(shù)被調(diào)用的次數(shù)相似，它們都花了很多的時間。

System.Collections.ArrayList.get_Count()

System.Collections.ArrayList.get_Item(int32)

System.String.op_Equality(string,string)

?

果凍：（大叫起來）當我寫這一個語句的時候

????? for (int i = 0; i < m_wordList.Count; i++)

沒想到m_wordList.Count，也就是ArrayList.GetCount()，會花這么多時間，累計被調(diào)用了1631884次！

我可以馬上把代碼改成：

??????????? int count = m_wordList.Count;

for (int i = 0; i < count; i++)

這樣會如何？大家等了一會兒，代碼分析的結(jié)果出來了（如圖9-4所示）：

圖9-4? 改進過的程序效能分析圖

可以看到System.Collections.ArrayList.get_Count()的調(diào)用次數(shù)和時間都大幅度地下降了。

我們可以繼續(xù)進行“效能測試，分析，改進，再效能測試”的流程，逐漸提高程序的效能和我們的編程水平。

大家也要注意避免沒有做分析就過早地進行“效能提高”，剛才有人提到我們可能要提高排序的性能，但是從圖9-4來看，System.Collections. ArrayList.Sort()只占了FreqOneWord()不到1/50的時間，如果我們不經(jīng)分析就盲目優(yōu)化，也許會事倍功半。

9.5? 本章討論

果凍：噫吁唏，危乎高哉！我以前一直害怕做效能分析，看來是否會用效能分析工具來提高程序質(zhì)量是一個優(yōu)秀程序員的標志之一。我在今天之前都是盲人騎瞎馬。

小飛：改成盲人摸象更恰當。我聽說，如果一個程序員從來沒有用過效能分析工具，那他就不是一個程序員，只是一個編程愛好者罷了。

我的WC 程序事實上是最快的。但是在今天的程序評比之前，我想更進一步，就再優(yōu)化了一下，估計能把速度提高2%。沒想到出了一個小錯誤，導致報告的結(jié)果（行數(shù)、詞數(shù)、字數(shù)）僅僅差了1。由于程序不正確，因此不能參加速度評比。我才是最需要大喊“噫吁唏”的人。

阿超：這有兩個教訓：

（1）先保證正確性，再提高效能。一個“僅僅差了1”的錯誤可能會導致緩沖區(qū)溢出（Buffer Overflow）的嚴重漏洞。

（2）如果效能的提高效果在5%以下，用戶不會注意到程序效能的區(qū)別。所以要考慮那些微小的提高是否值得。

另外，WordFreq算法的時間復雜度是多少，能否再優(yōu)化？請寫實際程序加以驗證。

荔荔：怎么才能快捷地得到有適量重復文字的文件，來幫助我們進行測試和效能分析？

九條：我是這樣做的，在電腦的根目錄下，運行“dir /s > c:\temp\test.txt”命令。

阿超：好主意，大家還有沒有別的辦法？

?

VS2012:

Visual Studio 2012 提供了更好的效能測試的功能, 請看這些博客:

　　http://www.cnblogs.com/smart-code/archive/2012/09/23/2699053.html?

　　http://www.cnblogs.com/Gun-N-Rose/archive/2012/09/23/2699220.html?

　　http://www.cnblogs.com/bigbadwolf/archive/2012/09/24/2699438.html??

　　http://www.cnblogs.com/Gun-N-Rose/archive/2012/09/24/2699804.html?

?

總結(jié)

以上是生活随笔為你收集整理的现代软件工程讲义 2 开发技术 - 效能分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。