目前所做的項(xiàng)目，今年應(yīng)該是第 5 個 release 了， ? 走過了這 5 年的風(fēng)風(fēng)雨雨，中間幾度更易開發(fā)人員，現(xiàn)在的團(tuán)隊(duì)與 5 年前的團(tuán)隊(duì)已是兩個完全沒有"交集"的團(tuán)隊(duì)， ? 這樣必然導(dǎo)致我們對項(xiàng)目會存在很多的不理解，不理解其初衷，不理解其原始設(shè)計(jì)，不理解其代碼。。。對一些不理解的地方不敢大動手腳，只能修修補(bǔ)補(bǔ)以完成需要的功能，其結(jié)局從開發(fā)角度看就是總體設(shè)計(jì)的缺失， ? 代碼結(jié)構(gòu)的混亂，從功能角度看就是容易出錯，運(yùn)行速度極慢。

項(xiàng)目極其需要一次深入的代碼重構(gòu)與性能提升，而這都至少需要一個 release 的時間來做，對于代碼重構(gòu)， ? 從商業(yè)的角度來講，是十分不可取的，一是其風(fēng)險(xiǎn)比較大，大刀闊斧的重構(gòu)，如何保證軟件的原有功能是個大問題； ? 而整整一個 release 的時間做重構(gòu)，對于用戶來講，他拿到新的版本時，看不到任何新功能與提高，難道你告訴他，我們的代碼結(jié)構(gòu)現(xiàn)在很 elegent 。。。；但對于性能提升，現(xiàn)在是到了不得不做的地步，因?yàn)槟軌虼蠓鹊奶嵘阅埽氡赜脩粢材芙邮芤粋€沒有新功能的新版本。

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

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

一、集中處理 ?(batch processing)

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

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

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

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

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

四、 cache 機(jī)制 ?(cache mechanism)

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

五、延遲更新 ?(defer update)

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

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

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

我對軟件優(yōu)化的一些想法