目前所做的項目，今年應該是第 5 個 release 了， ? 走過了這 5 年的風風雨雨，中間幾度更易開發人員，現在的團隊與 5 年前的團隊已是兩個完全沒有"交集"的團隊， ? 這樣必然導致我們對項目會存在很多的不理解，不理解其初衷，不理解其原始設計，不理解其代碼。。。對一些不理解的地方不敢大動手腳，只能修修補補以完成需要的功能，其結局從開發角度看就是總體設計的缺失， ? 代碼結構的混亂，從功能角度看就是容易出錯，運行速度極慢。

項目極其需要一次深入的代碼重構與性能提升，而這都至少需要一個 release 的時間來做，對于代碼重構， ? 從商業的角度來講，是十分不可取的，一是其風險比較大，大刀闊斧的重構，如何保證軟件的原有功能是個大問題； ? 而整整一個 release 的時間做重構，對于用戶來講，他拿到新的版本時，看不到任何新功能與提高，難道你告訴他，我們的代碼結構現在很 elegent 。。。；但對于性能提升，現在是到了不得不做的地步，因為能夠大幅度的提升性能，想必用戶也能接受一個沒有新功能的新版本。

于是， ? 我們決定用一個 release 的時間來做性能優化。

當然，我們不打算從學術的角度來考慮， ? 這個是 O(n)? 的算法，那個是 O(nlgn)? 的。。。； ? 也不打算從語言的角度來看待， ? 傳引用要比傳值快，類成員在初始化列表初始化。。。；當然， ? 并不是說這些不重要， ? 只是這些都應該是比較常見的，大家都應該清楚的事情， ? 也就是說我們假設我們的項目中不存在這種問題； ? 另外就是從語言角度來做的優化， ? 對我們的性能提升幫助不會太大。 ? 我們會從一個宏觀的，特定于我們項目 workflow 方面的角度來做優化。 ? 主要包括以下幾個方面：

一、集中處理 ?(batch processing)

把相關的操作集中起來處理， ? 從程序原理上來講， ? 集中做相同的操作， ? 由于數據局部性的原理， ? 很多數據可以直接從 cache 中取得， ? 速度會比較快。 ? 但我們主要考慮的還是另外一個因素，減少不必要的重復的初始化，假設將我有十個對象要 update ， ? 一般情況下， ? 為了做 update ， ? 我們必然要準備某些前提數據， ? 如果十個對象分別處理， ? 我就要初始化十次， ? 但如果我先把這十個對象收集起來，到最后一起處理， ? 最后只會初始化一次前提數據。 ? 這對于 update 對象密集的情況十分有用。 ? 當然， ? 這樣我們也能有效的減少函數調用次數， ? 對性能提高也有不少的幫助。

二、減少重復操作（初始化） ?(reduce?repeated operations)

重復操作， ? 一個是在有循環的時候， ? 我應該盡量把一些 common 的操作， ? 如一些輸入數據的初始化提到循環外面來做，這在上面一點中也提到過。 ? 二是對于一些全局的屬性，操作等， ? 我們應該放在內存里，并提供一個全局訪問點來直接得到， ? 而不是每次在需要的時候都去重新初始化一遍。 ? 舉個例子來講， ? 每個 application 應該都有他自己的一些 configuration, setting,? 如果每次我需要這些信息的時候， ? 都從文件，或者注冊表去讀一次， ? 那就非常的浪費時間了， ? 尤其是涉及到 I/O 操作的時候。 ? 當然， ? 這個有點像 ?cache 的概念， ? 但是還遠遠不及。

三、消除冗余操作 ?(avoid redundant operations)

也許你不相信， ? 一個項目經過很多不同的人的開發， ? 由于理解上的誤差，以及時間緊迫倉促完工，很多 workflow 上可能會都重復的操作， ? 仔細檢察， ? 從全局上來考慮整個流程，你會發現， ? 其實我們做了很多不該做的事。

四、 cache 機制 ?(cache mechanism)

Cache 的原理是用空間換時間， ? 當然，這個空間是指內存。我們把一些重要的中間信息放在內存中，以極大的提高查找，更新的速度。一般常用的數據結構就是 map,? 比如一個對象有長度這么一個屬性， ? 但每次去得這個長度的時候都需要經過復雜的耗時的計算， ? 如果我們有些操作需要大量的使用到這個對象及其屬性， ? 我們就可以建這樣一個 map: map< 對象指針，長度 > ， ? 這樣每次用到時， ? 我只要到這個 map 中去查就可以了， 如果某個對象被更新了，我們需要更新這個 map,? 也就是說維護 cache.

五、延遲更新 ?(defer update)

這是一個講究策略的做法， ? 比如說我們的項目要在 9.1 號前 demo 給客戶， ? 我們要寫好代碼，并維護好文檔， ? 但是時間很急， ? 如果我們在 9.1 號前把這兩件時都要做好，恐怕要瘋狂加班了， ? 但是我們知道，客戶只需要看到我們軟件運行的效果， ? 文檔他暫時并不關心， ? 那好吧， ? 我們 9.1 前就寫代碼， ? 文檔就在 demo 后寫好了。當然舉這個例子的并不是鼓勵大家先寫代碼，后補文檔， ? 而是為了說明有些事情， ? 如果資源緊張， ? 我們可以把他分開看待，對于要的不急的那部分， ? 我們可以先不做， ? 等到時不忙了， ? 需要了的時候再做， ? 以緩解當前的緊張。 ? 從代碼角度舉個例子， ? 假設我們有十條樣條曲線需要更新， ? 更新可能包括樣條線的方程，圖形顯示， ? 以及其長度等等， ? 如果我這些事情我一下子全做了， ? 用戶可能要等很久， ? 但是我們知道， ? 用戶做了這個操作， ? 他只需要看到圖形上更新就可以了， ? 至于長度等什么的， ? 等他需要了， ? 或者空閑的時候，我們再給他更新， ? 這就讓整個操作比較流暢了。

這是我通過這個 release 對軟件優化的一些想法，我相信現實中優化的方法是多種多樣的，我希望這篇文章能夠起到拋磚引玉的作用，希望大家能夠提出自己的一些經驗來共同分享。

http://www.cnblogs.com/baiyanhuang/archive/2009/09/16/1730743.html

我對軟件優化的一些想法