可以想象，如果不加以重視，編譯速度極有可能會成為開發過程中的壹個瓶頸。那麽，為什麽C++它就編譯的這麽慢呢？
我想最重要的壹個原因應該是C++基本的"頭文件-源文件"的編譯模型：
每個源文件作為壹個編譯單元，可能會包含上百甚至上千個頭文件，而在每壹個編譯單元，這些頭文件都會被從硬盤讀進來壹遍，然後被解析壹遍。
每個編譯單元都會產生壹個obj文件，然後所以這些obj文件會被link到壹起，並且這個過程很難並行。
這裏，問題在於無數頭文件的重復load與解析，以及密集的磁盤操作。
下面從各個角度給出壹些加快編譯速度的做法，主要還是針對上面提出的這個關鍵問題。
壹、代碼角度
在頭文件中使用前置聲明，而不是直接包含頭文件。
不要以為妳只是多加了壹個頭文件，由於頭文件的"被包含"特性，這種效果可能會被無限放大。所以，要盡壹切可能使頭文件精簡。很多時候前置申明某個namespace中的類會比較痛苦，而直接include會方便很多，千萬要抵制住這種誘惑；類的成員，函數參數等也盡量用引用，指針，為前置聲明創造條件。
使用Pimpl模式
Pimpl全稱為Private Implementation。傳統的C++的類的接口與實現是混淆在壹起的，而Pimpl這種做法使得類的接口與實現得以完全分離。如此，只要類的公***接口保持不變，對類實現的修改始終只需編譯該cpp；同時，該類提供給外界的頭文件也會精簡許多。
高度模塊化
模塊化就是低耦合，就是盡可能的減少相互依賴。這裏其實有兩個層面的意思。壹是文件與文件之間，壹個頭文件的變化，盡量不要引起其他文件的重新編譯；二是工程與工程之間，對壹個工程的修改，盡量不要引起太多其他工程的編譯。這就要求頭文件，或者工程的內容壹定要單壹，不要什麽東西都往裏面塞，從而引起不必要的依賴。這也可以說是內聚性吧。
以頭文件為例，不要把兩個不相關的類，或者沒什麽聯系的宏定義放到壹個頭文件裏。內容要盡量單壹，從而不會使包含他們的文件包含了不需要的內容。記得我們曾經做過這麽壹個事，把代碼中最"hot"的那些頭文件找出來，然後分成多個獨立的小文件，效果相當可觀。
其實我們去年做過的refactoring，把眾多DLL分離成UI與Core兩個部分，也是有著相同的效果的 - 提高開發效率。
刪除冗余的頭文件
壹些代碼經過上十年的開發與維護，經手的人無數，很有可能出現包含了沒用的頭文件，或重復包含的現象，去掉這些冗余的include是相當必要的。當然，這主要是針對cpp的，因為對於壹個頭文件，其中的某個include是否冗余很難界定，得看是否在最終的編譯單元中用到了，而這樣又可能出現在壹個編譯單元用到了，而在另外壹個編譯單元中沒用到的情況。
之前曾寫過壹個Perl腳本用來自動去除這些冗余的頭文件，在某個工程中竟然去掉多達了5000多個的include。
特別註意inline和template
這是C++中兩種比較"先進"的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡壹下。
二、綜合技巧
預編譯頭文件（PCH）
把壹些常用但不常改動的頭文件放在預編譯頭文件中。這樣，至少在單個工程中妳不需要在每個編譯單元裏壹遍又壹遍的load與解析同壹個頭文件了。
Unity Build
Unity Build做法很簡單，把所有的cpp包含到壹個cpp中(all.cpp) ,然後只編譯all.cpp。這樣我們就只有壹個編譯單元，這意味著不需要重復load與解析同壹個頭文件了，同時因為只產生壹個obj文件，在鏈接的時候也不需要那麽密集的磁盤操作了,估計能有10x的提高，看看這個視頻感受壹下其做法與速度吧。
ccache
compiler cache, 通過cache上壹次編譯的結果，使rebuild在保持結果相同的情況下，極大的提高速度。我們知道如果是build，系統會對比源代碼與目標代碼的時間來決定是否要重新編譯某個文件，這個方法其實並不完全可靠(比如從svn上拿了上個版本的代碼)，而ccache判斷的原則則是文件的內容，相對來講要可靠的多。很可惜的是，Visual Studio現在還不支持這個功能 - 其實完全可以加壹個新的命令，比如cache build，介於build與rebuild之間，這樣，rebuild就可以基本不用了。
不要有太多的Additional Include Directories
編譯器定位妳include的頭文件，是根據妳提供的include directories進行搜索的。可以想象，如果妳提供了100個包含目錄，而某個頭文件是在第100個目錄下，定位它的過程是非常痛苦的。組織好妳的包含目錄，並盡量保持簡潔。
三、編譯資源
要提高速度，要麽減少任務，要麽加派人手，前面兩個方面講得都是減少任務，而事實上，在提高編譯速度這塊，加派人手還是有著非常重要的作用的。
並行編譯
買個4核的，或者8核的cpu，每次壹build，就是8個文件並行著編，那速度，看著都爽。 要是妳們老板不同意，讓他讀讀這篇文章：Hardware is Cheap, Programmers are Expensive
更好的磁盤
我們知道，編譯速度慢很大壹部分原因是磁盤操作，那麽除了盡可能的減少磁盤操作，我們還可以做的就是加快磁盤速度。比如上面8個核壹塊工作的時候，磁盤極有可能成為最大的瓶頸。買個15000轉的磁盤，或者SSD，或者RAID0的，總之，越快越好。
分布式編譯
壹臺機子的性能始終是有限的，利用網絡中空閑的cpu資源，以及專門用來編譯的build server來幫助妳編譯才能從根本上解決我們編譯速度的問題，想想原來要build 1個多小時工程的在2分鐘內就能搞定，妳就知道妳壹定不能沒有它 - Incredibuild。
並行，其實還可以這麽做。
這是壹個比較極端的情況，如果妳用了Incredibuild，對最終的編譯速度還是不滿意，怎麽辦？其實只要跳出思維的框架，編譯速度還是可以有質的飛躍的 - 前提是妳有足夠多的機器：
假設妳有solution A和solution B，B依賴於A，所以必須在A之後Build B。其中A，B Build各需要1個小時，那麽總***要2個小時。可是B壹定要在A之後build嗎？跳出這個思維框架，妳就有了下述方案：
這樣，通過讓A的build與B的編譯並行，最後link壹下B中的project，整個編譯速度應該能夠控制在1個小時15分鐘之內。
同時開始build A和B 。
A的build成功，這裏雖然B的build失敗了，但都只是失敗在最後的link上。
重新link B中的project。