項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。

　　tmpfs

　　有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鐘，也許這個數字是有點夸張了，不過粗想想，把文件放到內存上做編譯應該是比在磁盤上快多了吧，尤其如果編譯器需要生成很多臨時文件的話。

　　這個做法的實現成本，在Linux中，直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求，也不用改動編譯環境。

　　mount -t tmpfs tmpfs ~/build -o size=1G

　　用2.6.32.2的Linux Kernel來測試一下編譯速度：

　　用物理磁盤：40分16秒

　　用tmpfs：39分56秒

　　呃……沒什么變化。看來編譯慢很大程度上瓶頸并不在IO上面。但對于一個實際項目來說，編譯過程中可能還會有打包等IO密集的操作，所以只要可能，用tmpfs是有益無害的。當然對于大項目來說，你需要有足夠的內存才能負擔得起這個tmpfs的開銷。

　　make -j

　　既然IO不是瓶頸，那CPU就應該是一個影響編譯速度的重要因素了。

　　用make -j帶一個參數，可以把項目在進行并行編譯，比如在一臺雙核的機器上，完全可以用make -j4，讓make多允許4個編譯命令同時執行，這樣可以更有效的利用CPU資源。

　　還是用Kernel來測試：

　　用make： 40分16秒

　　用make -j4：23分16秒

　　用make -j8：22分59秒

　　由此看來，在多核CPU上，適當的進行并行編譯還是可以明顯提高編譯速度的。但并行的任務不宜太多，一般是以CPU的核心數目的兩倍為宜。

　　不過這個方案不是完全沒有cost的，如果項目的Makefile不規范，沒有正確的設置好依賴關系，并行編譯的結果就是編譯不能正常進行。如果依賴關系設置過于保守，則可能本身編譯的可并行度就下降了，也不能取得的效果。

　　ccache

　　ccache用于把編譯的中間結果進行緩存，以便在再次編譯的時候可以節省時間。這對于玩Kernel來說實在是再好不過了，因為經常需要修改一些Kernel的代碼，然后再重新編譯，而這兩次編譯大部分東西可能都沒有發生變化。對于平時開發項目來說，也是一樣。為什么不是直接用make所支持的增量編譯呢？還是因為現實中，因為Makefile的不規范，很可能這種“聰明”的方案根本不能正常工作，只有每次make clean再make才行。

　　安裝完ccache后，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了(通常情況下/usr/local /bin會在PATH中排在/usr/bin前面)。

　　繼續測試：

　　用ccache的次編譯(make -j4)：23分38秒

　　用ccache的第二次編譯(make -j4)：8分48秒

　　用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒

　　看來修改配置(我改了CPU類型。..)對ccache的影響是很大的，因為基本頭文件發生變化后，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。