-j [N], --jobs[=N] 同時允許 N 個任務；無參數表明允許無限個任務。
最有用的是去掉.o之間的依賴關系檢查，但這樣做需要對自己的工程項目子程序文件非常了解
② 淺談怎樣加快C++代碼的編譯速度
C++代碼一直以其運行時的高性能高調面對世人， 但是說起編譯速度，卻只有低調的份了。比如我現在工作的源代碼，哪怕使用Incredibuild調動近百台機子，一個完整的build也需要四個小時，恐怖！！！雖然平時開發一般不需要在本地做完整的build，但編譯幾個相關的工程就夠你等上好一段時間的了（老外管這個叫monkey around，相當形象）。想想若干年在一台單核2.8GHZ上工作時的場景 - 面前放本書，一點build按鈕，就低頭讀一會書~~~往事不堪回首。 可以想像，如果不加以重視，編譯速度極有可能會成為開發過程中的一個瓶頸。那麼，為什麼C++它就編譯的這么慢呢？ 我想最重要的一個原因應該是C++基本的「頭文件-源文件」的編譯模型： 1.每個源文件作為一個編譯單元，可能會包含上百甚至上千個頭文件，而在每一個編譯單元，這些頭文件都會被從硬碟讀進來一遍，然後被解析一遍。 2.每個編譯單元都會產生一個obj文件，然後所以這些obj文件會被link到一起，並且這個過程很難並行。 這里，問題在於無數頭文件的重復load與解析，以及密集的磁碟操作。 下面從各個角度給出一些加快編譯速度的做法，主要還是針對上面提出的這個關鍵問題。 一、代碼角度 1、在頭文件中使用前置聲明，而不是直接包含頭文件。 不要以為你只是多加了一個頭文件，由於頭文件的「被包含」特性，這種效果可能會被無限放大。所以，要盡一切可能使頭文件精簡。很多時候前置申明某個namespace中的類會比較痛苦，而直接include會方便很多，千萬要抵制住這種誘惑；類的成員，函數參數等也盡量用引用，指針，為前置聲明創造條件。 2、使用Pimpl模式 Pimpl全稱為Private Implementation。傳統的C++的類的介面與實現是混淆在一起的，而Pimpl這種做法使得類的介面與實現得以完全分離。如此，只要類的公共介面保持不變，對類實現的修改始終只需編譯該cpp；同時，該類提供給外界的頭文件也會精簡許多。 3、高度模塊化 模塊化就是低耦合，就是盡可能的減少相互依賴。這里其實有兩個層面的意思。一是文件與文件之間，一個頭文件的變化，盡量不要引起其他文件的重新編譯；二是工程與工程之間，對一個工程的修改，盡量不要引起太多其他工程的編譯。這就要求頭文件，或者工程的內容一定要單一，不要什麼東西都往裡面塞，從而引起不必要的依賴。這也可以說是內聚性吧。 以頭文件為例，不要把兩個不相關的類，或者沒什麼聯系的宏定義放到一個頭文件里。內容要盡量單一，從而不會使包含他們的文件包含了不需要的內容。記得我們曾經做過這么一個事，把代碼中最「hot」的那些頭文件找出來，然後分成多個獨立的小文件，效果相當可觀。 其實我們去年做過的refactoring，把眾多DLL分離成UI與Core兩個部分，也是有著相同的效果的 - 提高開發效率。 4、刪除冗餘的頭文件 一些代碼經過上十年的開發與維護，經手的人無數，很有可能出現包含了沒用的頭文件，或重復包含的現象，去掉這些冗餘的include是相當必要的。當然，這主要是針對cpp的，因為對於一個頭文件，其中的某個include是否冗餘很難界定，得看是否在最終的編譯單元中用到了，而這樣又可能出現在一個編譯單元用到了，而在另外一個編譯單元中沒用到的情況。 之前曾寫過一個Perl腳本用來自動去除這些冗餘的頭文件，在某個工程中竟然去掉多達了5000多個的include。 5、特別注意inline和template 這是C++中兩種比較「先進」的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡一下。
③ 如何提高vs2010編譯速度
如果你的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
④ [Delphi]請教一下怎樣提高Delphi的編譯速度
關於編譯速度，這主要是因為C語言本身的特點。編譯器要在實際編譯你的代碼前先處理無數多的頭文件。可以用預編譯頭文件來極大地提高CB的編譯速度。TeamB的一個大拿有一篇文章講這個技巧，相信大家都看過了。我用了這個辦法，編譯起來挺快的。
我充分認可大家談的事實，CB現在擁有比Delphi少的多的用戶群和影響。我也承認Delphi是一個偉大的產品。但是，這不是因為Object Pascal如何如何優美，或者它相轉C＋＋有什麼內在的優勢。這是Borland的一個戰略錯誤，它為此付出的代價是失去了在編譯器方面它曾經擁有的優勢。其附產品是培養了一大批Object Pascal詩人，繁榮了世界文壇。
⑤ 如何提高Keil4的編譯速度
沒有必要提高Keil4的編譯速度，短小程序的編譯也就是點下滑鼠的功夫就完成了。
稍長一些程序，編譯也不過幾秒的事。也不是需要幾十分鍾，想提高速度。
如果程序真的很長，編譯就需要一點時間的，這提高不了速度。要提高速度，只能在寫程序時，盡量優化吧。
如果你的電腦編譯的時間很長的話，還是查一個系統的問題吧。
⑥ 如何提高大型工程的編譯速度
影響因素比較多：1文件的大小，文件大小指的是全部include後的大校2文件數量，編譯是一個一個文件進行的，所以你的工程的文件數量也有關系。3還有聲明的復雜程度，復雜聲明需要額外地計算。4最影響編譯速度的估計是C++的模板
⑦ 如何加快android Studio的編譯速度
作為一名Android程序員，選擇一個好的IDE工具可以使開發變得非常高效，很多程序員喜歡使用Google的AndroidStudio來進行開發，但使用起來有時會出現卡頓等問題。本文介紹了幾種優化AndroidStudio啟動、編譯、運行速度的方法。首先解決一個AndroidStudio啟動報錯的問題1、進入剛安裝的AndroidStudio目錄下的bin目錄。找到idea.properties文件，用文本編輯器打開。2、在idea.properties文件末尾添加一行：disable.android.first.run=true，然後保存文件。3、關閉AndroidStudio後重新啟動，便可進入界面。優化AndroidStudio啟動速度1、開啟gradle單獨的守護進程當AndroidStudio遇到錯誤的時候，往往會導致AndroidStudio掛掉，為了防止推出程序，則另外開啟一個線程來守護AndroidStudio的進程，具體操作。在C:\Users\.gradle這個目錄下，創建gradle.properties配置文件，復制以下配置進行優化。#Project-wideGradlesettings.org.gradle.daemon=trueorg.gradle.jvmargs=-Xmx2048m-XX:MaxPermSize=512m-XX:+HeapDumpOnOutOfMemoryError-Dfile.encoding=UTF-8org.gradle.parallel=trueorg.gradle.configureondemand=true這些配置文件主要就是增大gradle運行的java虛擬機的大小，讓gradle在編譯的時候使用獨立進程，讓gradle可以很好的運行。2、擴大內存64位：\studio64.exe.vmoptionsorstudio.exe.vmoptions32位：\studio.exe.vmoptionsorstudio.exe.vmoptions編輯這個文件，在最開始的兩行設置內存大小，類似於eclipse.ini中的配置。配置如下：-Xms256m-Xmx1024m3、優化編譯時VM大小選擇file->setting->compile添加如下參數：-Xmx1024m-XX:MaxPermSize=128m-XX:+HeapDumpOnOutOfMemoryError-Dfile.encoding=UTF-8具體參數大小視電腦配置而定。經過測試，編譯速度有很大提升，比較大的項目從之前的5-8分鍾可以減少到1-2分鍾。OneAPMMobileInsight能夠實時監測移動應用的真實用戶體驗，通過Agent實現端到端的應用性能分析。幫助用戶提高發現應用問題的速度。並且可以深入到代碼級進行應用性能問題剖析，通過可視化界面展示智能移動終端的實時運行狀態。
⑧ 一個C++工程中，許多個文件都include某一個類，當該類更新時，編譯速度太慢，怎麼辦
這是個好問題，雖然老生常談，但真正知道解決方案的人很少。《EffectiveC++》有介紹，同時推薦這本書給所有C++er。
一個組織有問題的大型項目中，影響編譯速度的最大問題就是頭文件形成龐大的依賴網路，其中一個頭文件修改就導致一大堆間接依賴的源代碼文件需要重新編譯。a.h包含b.h，b.h包含c.h，c.h又包含d.h，即使a.h和d.h似乎沒什麼關系，修改d.h的時候還是無可避免a.cc被重新編譯。
首先得知道C++一個特性，函數分為聲明和實現兩部分是人所皆知，但類也可以分為前置聲明和定義可能知道的人就比較少了，知道能怎麼用就更少了，其實就是可以用來解決編譯速度問題的。
⑨ 如何加快C++代碼的編譯速度
最重要的一個原因應該是C++基本的"頭文件-源文件"的編譯模型：
每個源文件作為一個編譯單元，可能會包含上百甚至上千個頭文件，而在每一個編譯單元，這些頭文件都會被從硬碟讀進來一遍，然後被解析一遍。
每個編譯單元都會產生一個obj文件，然後所以這些obj文件會被link到一起，並且這個過程很難並行。
這里，問題在於無數頭文件的重復load與解析，以及密集的磁碟操作。