一次關(guān)于旨在降低編譯時(shí)間的整改工作（vc++）
[轉(zhuǎn)自]天爬者
由于工程的文件的日益龐大和第3方庫(ACE Loki Boost等等)的使用增多
我所工作的項(xiàng)目系統(tǒng)構(gòu)建時(shí)間從最初的3分鐘變?yōu)楝F(xiàn)在的8分鐘
程序員的機(jī)器配置已經(jīng)很不錯(cuò)了，3。0 的主頻1g的內(nèi)存，但是常常由于一個(gè)小的修改導(dǎo)致5分鐘甚至更長的編譯時(shí)間來驗(yàn)證效果。
按照《Joel on software》的說法，其直接后果是可怕的：
程序員們?cè)谶@8分鐘內(nèi)無所事事，只有查看網(wǎng)頁，或者qqmsn，打斷先前的思路從他們的上下文環(huán)境里面脫離了出來，離開了“順勢工作時(shí)間”，等到他們編譯好了驗(yàn)證再修改的時(shí)候，他們又得花不少的時(shí)間來回到剛才的思路
“順勢工作時(shí)間”大致意思就是說2個(gè)不連續(xù)的半小時(shí)的效果遠(yuǎn)不如一個(gè)連續(xù)沉浸的1小時(shí)的工作效果，如果一個(gè)人不能連續(xù)沉浸的思考，那么他就很可能陷入在不停的上下文環(huán)境切換和淺表思考當(dāng)中。人的多線程處理和機(jī)器是一樣的環(huán)境的切換不能夠不考慮
所以，在當(dāng)前機(jī)器配置已經(jīng)沒有什么提升空間的情況下，我在項(xiàng)目組內(nèi)部組織了一次整改活動(dòng)，旨在降低編譯構(gòu)建時(shí)間
1。目標(biāo)：將完全重新編譯時(shí)間從8分鐘降低到4分鐘以下
2。原則：通過和主程序的溝通，并參考了《C＋＋ coding Standards》出了一下幾條整改原則:
?????首先是關(guān)于include的，因?yàn)榘^文件相當(dāng)于將代碼復(fù)制到本文件來編譯，而頭文件又經(jīng)常是用來被別人包含的，所以工程文件多了，每個(gè)文件都有include鏈（包含的文件又include了其他文件），該鏈條不會(huì)止步于你工程，而會(huì)延伸到你所有使用的第3方庫里面
?????A.
能夠去掉的include就去掉。
?????B.能夠在cpp
里面include的頭文件不要在頭文件里面include。
?????說明：盡量去掉每個(gè)cpp會(huì)被串起來的頭文件膨脹的機(jī)會(huì)
?????
C.能夠用前向聲明的就不要include，頭文件里面也是一樣
???? 說明：在頭文件里面用前向聲明然后保存指針或者引用，在具體實(shí)現(xiàn)的cpp里面再包含頭文件，雖然看起來和《C＋＋ coding Standards》“
Make header files self-sufficient
”有些沖突（前兩天另外cppblog一位朋友講過
http://m.shnenglu.com/flyingxu/archive/2006/06/23/8908.html
）但是在一些核心的.h(被很多類include的)里面作改造工作，還是能夠收到很大的降低編譯時(shí)間效果，而付出的代價(jià)就是原來只需要包含該頭文件就可以編譯成功的cpp需要額外包含一些頭文件。
舉個(gè)例子： Foo類頭文件使用了前向申明保存了A類和B類的指針或者引用為成員變量，在Foo類的cpp里面才包含A和B的頭文件，而當(dāng)C類需要使用Foo類時(shí)候包含F(xiàn)oo類的頭文件，但是操作中又需要調(diào)用A的成員函數(shù)，C不同時(shí)包含A的頭文件的花就會(huì)出現(xiàn)編譯失敗。
雖然表面上是讓代碼更加復(fù)雜了，但是除卻帶來降低編譯時(shí)間的好處之外，代碼也在強(qiáng)迫你進(jìn)行解耦合，如果說你cpp里面需要包含的頭文件越多，說明你這個(gè)類需要知道的對(duì)象就越多，你可以乘機(jī)檢查一下自己的代碼又沒有不必要的耦合，為什么這個(gè)cpp需要知道那么多的本來可能屬于別的類的細(xì)節(jié).....
??????D。
把大多數(shù)模塊都要使用的庫文件或者穩(wěn)定類的頭文件include放到預(yù)編譯頭文件“stdafx.h”里面
??????說明：由于預(yù)編譯頭文件里面include的內(nèi)容只會(huì)compile一次而被link多次，把一些常用類放到這里會(huì)降低很多編譯時(shí)間，但也不能亂來，要點(diǎn)在于 “大多數(shù)”和“穩(wěn)定”，如果一個(gè)頭文件經(jīng)常變化，他的一次小改動(dòng)都會(huì)引起整個(gè)工程rebuild，哪怕只是一個(gè)注釋，因?yàn)樗械腸pp文件都包含了stdafx.h而stdafx.h又包含了這個(gè)容易變動(dòng)的頭文件。
??????
??????
E.使用Pimpl慣用法
??????說明：關(guān)于Pimpl大家可以查下資料，《C＋＋ coding Standards》里面也有講解，基本上就是采用一個(gè)私有的前向申明的stuct指針把所有protect成員都封裝起來起來.基本上是一個(gè)最終極的解決方案，但是對(duì)我們現(xiàn)有架構(gòu)改造太大，不敢全面實(shí)行，我們只選擇了數(shù)個(gè)最有價(jià)值的類進(jìn)行了改造，打算以后在其他項(xiàng)目里面再全面應(yīng)用。
3。實(shí)施： 通過半個(gè)小時(shí)的溝通，讓項(xiàng)目組程序員了解原則，并采取結(jié)隊(duì)修改的方式來降低引入新bug的風(fēng)險(xiǎn)，在以通過原有單元測試用例的條件下，進(jìn)行修改－測試－提交的迭代。
???
4。結(jié)果：???編譯時(shí)間降低到了6分鐘以內(nèi)。。。雖沒有達(dá)到預(yù)期，但也算有效果，沒有完全達(dá)標(biāo)的主要原因還是沒有完整的測試方案包括單元測試和驗(yàn)收測試，怕有些改動(dòng)過大影響系統(tǒng)健壯性，局部放棄了一些實(shí)施的原則。
把這個(gè)整改的工作寫出來，一方面作個(gè)記錄，另外一方面希望和大家討論，相互多多交流：）
posted on 2006-07-04 03:38
Jerry Cat 閱讀(535)
評(píng)論(1) 編輯 收藏 引用