1. 關於c++編譯生成文件
APS：存放二進制資源的中間文件，VC把當前資源文件轉換成二進制格式，並存放在APS文件中，以加快資源裝載速度。資源輔助文件。
.BMP：點陣圖資源文件。
.BSC：瀏覽信息文件，由瀏覽信息維護工具（BSCMAKE）從原始瀏覽信息文件（.SBR）中生成，BSC文件可以用來在源代碼編輯窗口中進行快速定位。用於瀏覽項目信息的，如果用source brower的話就必須有這個文件。可以在project options里去掉Generate Browse Info File，這樣可以加快編譯進度。
.C：用C語言編寫的源代碼文件。
.CLW：ClassWizard生成的用來存放類信息的文件。classwizard信息文件，ini文件的格式。
.CNT：用來定義幫助文件中「Contents」的結構。
.CPP或.CXX：用C++語言編寫的源代碼文件。
.CUR：游標資源文件。
.DEF：模塊定義文件，供生成動態鏈接庫時使用。
.DLG：定義對話框資源的獨立文件。這種文件對於VC工程來說並非必需，因為VC一般把對話框資源放在.RC資源定義文件中。
.DSP：VC開發環境生成的工程文件，VC4及以前版本使用MAK文件來定義工程。項目文件，文本格式。
.DSW：VC開發環境生成的WorkSpace文件，用來把多個工程組織到一個WorkSpace中。工作區文件，與.dsp差不多。
.EXP：由LIB工具從DEF文件生成的輸出文件，其中包含了函數和數據項目的輸出信息，LINK工具將使用EXP文件來創建動態鏈接庫。只有在編譯DLL時才會生成，記錄了DLL文件中的一些信息。
.H、.HPP或.HXX：用C/C++語言編寫的頭文件，通常用來定義數據類型，聲明變數、函數、結構和類。
.HLP：Windows幫助文件。
.HM：在Help工程中，該文件定義了幫助文件與對話框、菜單或其它資源之間ID值的對應關系。
.HPJ：由Help Workshop生成的Help工程文件，用來控制Help文件的生成過程。
.HPG，生成幫助的文件的工程。
.ICO：圖標資源文件。
.ILK：連接過程中生成的一種中間文件，只供LINK工具使用。
.INI：配置文件。
.LIB：庫文件，LINK工具將使用它來連接各種輸入庫，以便最終生成EXE文件。
.LIC：用戶許可證書文件，使用某些ActiveX控制項時需要該文件。
.MAK：即MAKE文件，VC4及以前版本使用的工程文件，用來指定如何建立一個工程，VC6把MAK文件轉換成DSP文件來處理。
.MAP：由LINK工具生成的一種文本文件，其中包含有被連接的程序的某些信息，例如程序中的組信息和公共符號信息等。執行文件的映像信息記錄文件。
.MDP：舊版本的項目文件，相當於.dsp
.NCB：NCB是「No Compile Browser」的縮寫，其中存放了供ClassView、WizardBar和Component Gallery使用的信息，由VC開發環境自動生成。無編譯瀏覽文件。當自動完成功能出問題時可以刪除此文件。編譯工程後會自動生成。
.OBJ：由編譯器或匯編工具生成的目標文件，是模塊的二進制中間文件。
.ODL：用對象描述語言編寫的源代碼文件，VC用它來生成TLB文件。
.OLB：帶有類型庫資源的一種特殊的動態鏈接庫，也叫對象庫文件。
.OPT：VC開發環境自動生成的用來存放WorkSpace中各種選項的文件。工程關於開發環境的參數文件。如工具條位置信息等。
.PBI、.PBO和.PBT：由VC的性能分析工具PROFILE生成並使用的三種文件。
.PCH：預編譯頭文件，比較大，由編譯器在建立工程時自動生成，其中存放有工程中已經編譯的部分代碼，在以後建立工程時不再重新編譯這些代碼，以便加快整個編譯過程的速度。
.PDB：程序資料庫文件，在建立工程時自動生成，其中存放程序的各種信息，用來加快調試過程的速度。記錄了程序有關的一些數據和調試信息。
.PLG：編譯信息文件，編譯時的error和warning信息文件。
.RC：資源定義文件。
.RC2：資源定義文件，供一些特殊情況下使用。
.REG：注冊表信息文件。
.RES：二進制資源文件，資源編譯器編譯資源定義文件後即生成RES文件。
.RTF：Rich Text Format（豐富文本格式）文檔，可由Word或寫字板來創建，常被用來生成Help文件。
.SBR：VC編譯器為每個OBJ文件生成的原始瀏覽信息文件，瀏覽信息維護工具（BSCMAKE）將利用SBR文件來生成BSC文件。
.TLB：OLE庫文件，其中存放了OLE自動化對象的數據類型、模塊和介面定義，自動化伺服器通過TLB文件就能了解自動化對象的使用方法。
debug 包裡面有生成的可執行文件，及有關鏈接庫的一些信息，調試信息等
2. 如何提高ISE的編譯速度
如果你的cpu夠強你應該學會如何利用好它來加速你的代碼編譯速度，那麼你怎麼才能夠最大限度讓你的cpu發燒呢？
下面是一個對比：
比如我的cpu是i7 3770k，
編譯cocos2d-x的libcocos2d工程：
不優化：
1>Time Elapsed 00:01:35.25
優化後：
1>Time Elapsed 00:00:21.66
效果顯著！！！
參考網頁：
Visual Studio 2010中C++並行構建調優(1)
http://developer.51cto.com/art/201003/189235.htm
1>cl : Command line warning D9030: '/Gm' is incompatible with multiprocessing; ignoring /MP switch
解決辦法是：
Properties -> Configuration Properties -> C/C++ -> Code Generation -> Enable Minimal Rebuild -> No(/Gm-)
Properties -> Configuration Properties -> C/C++ -> Geneal -> Multi-processor Compilation -> Yes(/MP)
一些含義和拓展資料：
Enable minimal rebuild
通過保存關聯信息到.IDB文件，使編譯器只對最新類定義改動過的源文件進行重編譯，提高編譯速度
Enable Incremental Compilation
同樣通過.IDB文件保存的信息，只重編譯最新改動過的函數
/MP (Build with Multiple Processes)
http://msdn.microsoft.com/en-us/library/bb385193.aspx
/Gm (Enable Minimal Rebuild)
http://msdn.microsoft.com/en-us/library/kfz8ad09.aspx
3. Xcode 構建速度優化（一）衡量編譯時間
隨著項目不斷迭代，工程文件越來越多，引用的三方庫也越來越多，這些直接導致編譯時間的不斷增加，完整編譯一次項目動輒需要五分鍾以上時間，實在有些影響開發效率，是時候來一波提速了。
為編譯和構建提速，首先我們需要對速度有一個衡量標准：准確獲得構建用時
首先，我們需要定義要衡量和優化的內容。 有兩種選擇：
xcode默認情況下會跟蹤所有構建，我們可以通過更改xcode相關設置，來在活動查看器中顯示出構建時間，通過命令行：
每次編譯成功後，會在Successed之後顯示出所用時間:
Xcode Build Timing Summary是Xcode10中加入的用於查看獲取構建時間和發現用時瓶頸方面的最有利工具。 可以通過Proct->Perform Action->Build With Timing Summary來開啟：這樣在 Build Log 的末尾就會添加 Timing Summary Log。我們可以通過這個 log 看到哪個階段是耗時的，便於我們進行優化。
如上圖中: xib階段的編譯耗時明顯是比普通c文件要多的，意味著我們可以通過減少xib方式來優化提升速度
而c文件的編譯用時比總時間還要長，是因為c文件是並行編譯的
在命令行中同樣可以開啟這個功能：
常用的第三方工具有 BuildTimeAnalyzer 、 xcode-build-times-rendering 、 XCLogParser 。
BuildTimeAnalyzer可以統計可以得出某個文件的類型檢查時長，每個表達式的類型檢查時長。
xcode-build-times-rendering是一個Ruby編寫的第三方工具，可以方便地分別測量目標的構建時間並在圖表上顯示它們，使用gem安裝
接下來使用這個工具自帶命令配置項目
然後構建項目並生成報告：
這個工具使用上比較簡單，缺點是只能從宏觀上生成各個target編譯的整體圖標，無法詳細列出各個內部編譯明細
XCLogParser可以詳細列出各個Target和內部每個文件的編譯耗時，對我們分析編譯時間瓶頸非常有幫助，它的工作原理主要是做為解析器，通過解析xcode編譯生成的xcactivitylog日誌來記錄
安裝：
編譯項目後，進行安裝
安裝成功後通過命令：
會自動在當前目錄的 build/xclogparser/reports/ 路徑下生成報告，其中--project參數需要設置為待分析項目的名字，並注意當前在終端切換到希望寫入日誌的目錄。
報告截圖：
這個工具將作為我們後面分析提升編譯構建速度的主要使用工具。
經過我多次在不同時間段，不同電腦上不斷嘗試編譯，
我發現編譯耗時是一個比較玄的東西，及時在同一台電腦，同一個項目， 同一套環境配置下，編譯用時也會隨著電腦當前狀態（包括同時打開進程、散熱等等）上下大幅跳動，就像演算法時間復雜度一樣，有時候我們明明做了一些細微的優化，但是結果反而是編譯耗時增加了，這是很正常的事情
所以，衡量這個標准需要我們取多次試驗中的平均值作為參考。
4. C語言多充循環，運算次數多，編譯時間很長，又無法估計最終需要多久，怎麼辦
如果要減少時間 那麼優化代碼，或者直接改進演算法
如果要預測時間，那麼大致估計一下循環的次數，然後在固定的某個循環中加一個列印，通過列印頻率來估算總時間
項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache，可以將ccache的緩存文件設置在tmpfs上，但是這樣的話，每次開機後，ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中，避免終端設備（慢速設備）拖慢速度。
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工作原理：
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存，必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的，確保了與直接使用GCC獲得完全相同的輸出。
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前面）。
安裝的另外一種方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++，而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時，使用g++編譯器時會自動啟動ccache
繼續測試：
用ccache的第一次編譯(make -j4)：23分38秒
用ccache的第二次編譯(make -j4)：8分48秒
用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒
看來修改配置（我改了CPU類型...）對ccache的影響是很大的，因為基本頭文件發生變化後，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，顯然只有第二編次譯時cache命中了，cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟，還是完全可以接受的。
distcc
一台機器的能力有限，可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的，因為可能每個開發人員都有自己的開發編譯環境，它們的編譯器版本一般是一致的，公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc，並不像想像中那樣要求每台電腦都具有完全一致的環境，它只要求源代碼可以用make -j並行編譯，並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上，預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成，所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後，可以啟動一下它的服務：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數，設置可以參與編譯的機器列表。通常localhost也參與編譯，但如果可以參與編譯的機器很多，則可以把localhost從這個列表中去掉，這樣本機就完全只是進行預處理、分發和鏈接了，編譯都在別的機器上完成。因為機器很多時，localhost的處理負擔很重，所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++，gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候，也必須用-j參數，一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下：
一台雙核計算機，make -j4：23分16秒
兩台雙核計算機，make -j4：16分40秒
兩台雙核計算機，make -j8：15分49秒
跟最開始用一台雙核時的23分鍾相比，還是快了不少的。如果有更多的計算機加入，也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用，通過設置一個環境變數就可以做到，非常方便。
總結一下：
tmpfs： 解決IO瓶頸，充分利用本機內存資源
make -j： 充分利用本機計算資源
distcc： 利用多台計算機資源
ccache： 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低，綜合利用這些工具，就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法，更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。
6. 關於如何提高keil的編譯速度
Project -> Options for Target -> C/C++下面勾選「Optimize for Time」優化時間，即優化代碼中費時的地方。
Keil（MDK-ARM）系列教程（四）_工程目標選項配置（Ⅱ）：
http://blog.csdn.net/ybhuangfugui/article/details/53131141
Keil系列教程：
http://blog.csdn.net/column/details/13472.html
7. 如何加快xcode編譯速度
1. 增加XCode執行的線程數
可以根據自己Mac的性能，更改線程數設置5：defaults write com.apple.Xcode 5
另外也有一個設置可以開啟：defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES
XCode默認使用與CPU核數相同的線程來進行編譯，但由於編譯過程中的IO操作往往比CPU運算要多，因此適當的提升線程數可以在一定程度上加快編譯速度。
2.將Debug Information Format改為DWARF
在工程對應Target的Build Settings中，找到Debug Information Format這一項，將Debug時的DWARF with dSYM file改為DWARF。
這一項設置的是是否將調試信息加入到可執行文件中，改為DWARF後，如果程序崩潰，將無法輸出崩潰位置對應的函數堆棧，但由於Debug模式下可以在XCode中查看調試信息，所以改為DWARF影響並不大。這一項更改完之後，可以大幅提升編譯速度。
比如在目前本人負責的項目中，由於依賴了多個Target，所以需要在每個Target的Debug Information Format設置為DWARF。順便提一下，如果通過Cocoapod引入第三方則Debug Information Format默認就是設置為DWARF的。
SDWebImage通過Cocoapod``Debug Information Format的默認設置
注意：將Debug Information Format改為DWARF之後，會導致在Debug窗口無法查看相關類類型的成員變數的值。當需要查看這些值時，可以將Debug Information Format改回DWARF with dSYM file，clean（必須）之後重新編譯即可。
3.將Build Active Architecture Only改為Yes
在工程對應Target的Build Settings中，找到Build Active Architecture Only這一項，將Debug時的NO改為Yes。
664334-fa1eb995c140ce0f.png
這一項設置的是是否僅編譯當前架構的版本，如果為NO，會編譯所有架構的版本。需要注意的是，此選項在Release模式下必須為NO`，否則發布的ipa在部分設備上將不能運行。這一項更改完之後，可以顯著提高編譯速度。
4.設計編譯優化等級
不要再項目中或者靜態庫中使用-O4，因為這會讓Clang鏈接Link Time Optimizations (LTO)使得編譯更慢，通常使用-O3。
注意：在設置編譯優化之後，XCode斷點和調試信息會不正常，所以一般靜態庫或者其他Target這樣設置。
4.資源整合
4.1 將常用的代碼及文件打包成靜態庫
4.2 添加預編譯文件，把常用的頭文件放到預編譯文件裡面
4.3 能用@class就用@class
8. c++builder編譯速度太慢，能不能通過設置來加快
C＋＋builder是最快的C＋＋編譯器之一，從編譯速度來說也可以說是最快的win32C＋＋編譯器了。除了速度之外，C++builder的性能也在其它C＋＋編譯器的之上，但許多delphi程序員仍受不了c++builder工程的編譯速度。的確，delphi的速度要比任和c++的編譯器都要快好多。Delphi在編譯一個小工程的時候可能不到一秒，大的工程一般也在5秒鍾這內編譯完成了。
為什麼delphi會比c++builder快這么多？是否有方法來c++builder的編譯速度？本文就講解了為什麼C＋＋的編譯器速度會慢，並且介紹了一個簡單的方法來減少c++builder的編譯時間。
為什麼c++編譯器的速度會慢？
c++builder 使用者怎麼通過預編譯頭文件來減少編譯時間？
講解基於VCL可視化工程的預編譯頭文件方法
優化c++builder對預編譯頭文件的使用
結論
注意事項
為什麼c++編譯器速度慢？
在C＋＋中，你只能使用預定義或是預先聲明了的函數，這意味什麼？來看一個簡單的例子，函數A()調用函數B（），函數A（）只能在函數B（）的原型或是函數體在A（）之前才能調用它