C程式最佳化之路（三）

 本文講述在編寫C程式碼的常用最佳化辦法，分為I/O篇，記憶體篇，演算法篇。MMX本來我也想歸在這裡的，但是由於內容和標題不太符和，決定換一個名字，叫MMX技術詳解，和H263視頻壓縮技術中的MMX應用兩篇文章。

三．演算法篇

       在上一篇中我們講述了對記憶體操作的最佳化，這一篇則主要講述一些常用的最佳化演算法。這個東東太多，內容可能會有點淩亂，見諒。

I．從小處說起：

       先說說一些小地方先：

① 比如n/2寫為n>>1這個是常用的方法，不過要注意的是這兩個不是完全等價的！因為：如果n＝3的話，n/2=1;n>>1=1;但是，如果n＝-3的話，n/2=-1;n>>1=-2所以說在正數的時候，他們都是向下取整，但是負數的時候就不一樣了。（在JPG2000中的整數YUV到RGB變換一定要使用>>來代替除法就是這個道理）

② 還有就是a=a+1要寫為a++;  a=a+b要寫為a+=b（估計一般用VB的才會寫a=a+1 ）

③ 將多種運算融合：比如a[i++];就是先訪問a[i]，再令i加1；從彙編的角度上說，這個確實是最佳化的，如果寫為a[i]，和i++的話，有可能就會有兩次的對i變數的讀，一次寫（具體要看編譯器的最佳化能力了），但是如果a[i++]的話，就一定唯讀寫i變數一次。不過這裡有一個問題要注意：在條件判斷內的融合一定要小心，比如：（idct變換中的0塊判斷，陳王演算法）

  if (!((x1 = (blk[8*4]<<8)) | (x2 = blk[8*6]) | (x3 = blk[8*2]) | (x4 = blk[8*1]) | (x5 = blk[8*7]) | (x6 = blk[8*5]) | (x7 = blk[8*3])))

在條件判斷中融合了指派陳述式，但是實際上如果條件為真的話，是不需要這些指派陳述式的，也就是說當條件真的時候，多了一些垃圾語句，這些是在h263源碼上的問題，雖然這些垃圾語句使得計算0塊的時候，時間增加了30％，但是由於idct僅僅佔1%的時間，0塊又僅僅30%~70%的時間，所以這些效能損失是沒有什麼關係的。（這是後來我用彙編改寫源碼的時候得到的結論）。這裡也說明了，程式最佳化一定重點在最耗時的地方。對於不耗時的代碼最佳化是沒有太大的實用意義的。

II．以記憶體換速度：

天下總是難有雙得的事情，編程也是一樣，大多數情況，速度同記憶體（或者是效能，比如說壓縮效能什麼的）是不可兼得的。目前程式加速的常用演算法一個大方面就是利用查表來避免計算（比如在jpg有huffman碼錶，在YUV到RGB變換也有變換表）這樣原來的複雜計算現在僅僅查表就可以了，雖然浪費了記憶體，不過速度顯著提升，還是很划算的。在資料庫查詢裡面也有這樣的思想，將熱點儲存起來以加速查詢。 現在介紹一個簡單的例子，（臨時想的，呵呵）：比如，在程式中要經常（一定要是經常！）計算1000到2000的階乘，那麼我們可以使用一個數組a[1000]先把這些值算好，保留下來，以後要計算1200！的時候，查表a[1200-1000]就可以了。

III．化零為整

       由於零散的記憶體配置，以及大量小對象建立耗時很大，所以對它們的最佳化有時會很有效果，比如上一篇我說的鏈表存在的問題，就是因為大量的零散記憶體配置。現在就從一個vb的程式說起，以前我用vb給別人編小程式的時候，（呵呵，主要是用vb編程比vc快，半天就可以寫一個）在使用MSFlexGrid控制項的時候（就是一個表格控制項），發現如果一行一行的增加新行，重新整理速度十分的慢，所以我就每次增加100行，等到資料多到再加新行的時候，再加100行，這樣就“化零為整”了，使用這樣的方法，重新整理的速度比原來快了n倍！其實這樣的思想應用很多，如：程式啟動並執行時候，其實就佔用了一定的空間，後來的小塊記憶體配置是先在這個空間上的，這就保證了記憶體片段儘可能的少，同時加快運行速度。

IV．條件陳述式或者case語句將最有可能的放在前面

       最佳化效果不明顯。想得到就用吧，想不到就算了。

V．為了程式的可讀性，不去做那些編譯器可以做的或者最佳化不明顯的處理：

       這個是很重要的，一個普通程式的好壞，主要是它的可讀性，可移植性，可重用性，然後才是它的效能。所以，如果編譯器本身可以協助我們最佳化的話，我們就沒有必要寫那些大家都不怎麼看得懂的東西。比如a＝52（結束）－16（起始）；這樣寫可能是因為在別人讀程式的時候，一下就明白了a的含義。我們不用寫為a＝36，因為編譯器是會幫我們算出來的。

IV．具體情況具體分析：

       具體情況具體分析，這是放之四海而皆準的真理。沒有具體的分析，就不能針對問題靈活應用解決的辦法。下面我就說說分析的方法。即如何找到程式的耗時點：（從最簡單的辦法說起，先說明一個函數GetTickCount(),這個函數在頭尾各調用一次，傳回值相減就是程式的耗時，精確到1ms）

① 對於認為是比較耗時的函數，運行兩次，或者將函數內部的語句注釋掉（要保證程式可以運行），看看多（或者少了）多少時間。這個辦法簡單不精確。

② 每個地方都用GetTickCount()函數測試時間，注意GetTickCount()只能精確到ms。一般的小於10ms就不太精確了。

③ 使用另外一個函數QueryPerformanceCounter（&Counter）和QueryPerformanceFrequency(&Frequency)，前面計算cpu刻度，後面是cpu頻率相除就是時間。不過如果你要精確到這一步的話，建議將進程設定為最進階別，防止它被阻塞。

最後講講我處理的一個程式：程式要求我忘了，反正裡面有一個函數，函數裡面有一個大的迴圈，迴圈內部的處理比較耗時。結果最初程式表現出來的狀況是開始還很快，越到後面越慢；我在跟蹤程式中變數的時候，發現最初的迴圈在迴圈幾次後就跳出了，而後面的迴圈次數越來越多。找到了為什麼慢的原因，就可以對症下藥了，我的處理是每次迴圈不是從頭開始，而是從上一次迴圈跳出的地方開始左右迴圈（因為可能下一次迴圈跳出的地方別上一次的小，所以也要遍曆前面的），這樣程式的速度在後面也很快了。我講這個的道理就是在實際運用中，要具體的剖析器慢的真正原因，才能達到最佳的最佳化效果。