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