本文講述在編寫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 :P）
③ 將多種運算融合：比如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頻率相除就是時間。不過如果你要精確到這一步的話，建議將進程設置爲最高級別，防止它被阻塞。
最 後講講我處理的一個程序：程序要求我忘了，反正裏面有一個函數，函數裏面有一個大的循環，循環內部的處理比較耗時。結果最初程序表現出來的狀況是開始還很 快，越到後面越慢；我在跟蹤程序中變量的時候，發現最初的循環在循環幾次後就跳出了，而後面的循環次數越來越多。找到了爲什麼慢的原因，就可以對症下藥 了，我的處理是每次循環不是從頭開始，而是從上一次循環跳出的地方開始左右循環（因爲可能下一次循環跳出的地方別上一次的小，所以也要遍歷前面的），這樣 程序的速度在後面也很快了。我講這個的道理就是在實際運用中，要具體的分析程序慢的真正原因，才能達到最佳的優化效果。