因為我們整個項目都是使用c++開發的，生成的so足有50M，原來編譯一遍要三五分鍾，一個針對oracle，一個針對mysql，整個輪回下來這部分就要10來分鍾，加上代碼上傳、翻譯，一輪配管打包下來二三十分鍾。BOSS有些生氣，效率比較低。今天一大早到公司就着手測試。經在本地vmware測試，編譯gperftools的速度從2分30秒下降到1分。立刻讓項目組安排調整。原來配管只有一個cpu核，經過讓升級到4核，加上使用ccache，不需要修改任何編譯選項，快的不行。使用如下：
- 安裝ccache
yum install ccache - 查看ccache 安裝位置
whereis ccache
查看安裝路徑, /usr/bin/ccache - 創建gcc,g++鏈接
mkdir ~/.bin
cd ~/.bin/
ln -s /usr/bin/ccache gcc
ln -s /usr/bin/ccache g++ - 設置PATH,更改本地.bash_profile文件，修改gcc,g++鏈接到ccache
vim ~/.bashrc
添加 export PATH=$HOME/.bin:$PATH - 確認是否生效
which g++
如果是$HOME/.bin/g++就成功了；
直接編譯項目，飛一樣的感覺。
經查，gcc還支持多核編譯，還沒有測試（因為我們已經超級快了），有興趣的可以參考https://www.cnblogs.com/jacktu/archive/2010/07/15/1777974.html。
最近配管測試下來，ccache有個問題，就是如果頭文件都變了的化，第一次編譯的時候就和平常一樣了，比較慢，此時還是需要借助gcc的-j8進行多核編譯。不過通常來說，大型文件每次變更所有頭文件的概率是很小的，變化的只是一小部分，我們也發現了目前每天發布都是一個版本，導致頭文件變更存在問題，已經在研究根據模塊修改，而不是一擼子全部在一個大版本號中。這也充分說明了邏輯架構如果錯了，實現再優秀沒有用。就像我們要造一輛每次可以運50人的車，如果設計出來是跑車的架子，怎么地都是很難達到好的目標的。