編譯速度

① 淺談怎樣加快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++中兩種比較「先進」的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡一下。

② 如何加快C++代碼的編譯速度

最重要的一個原因應該是C++基本的"頭文件-源文件"的編譯模型：
每個源文件作為一個編譯單元，可能會包含上百甚至上千個頭文件，而在每一個編譯單元，這些頭文件都會被從硬碟讀進來一遍，然後被解析一遍。
每個編譯單元都會產生一個obj文件，然後所以這些obj文件會被link到一起，並且這個過程很難並行。
這里，問題在於無數頭文件的重復load與解析，以及密集的磁碟操作。

③ c語言的編譯效率是最快的嗎

計算機不能直接理解高級語言，只能直接理解機器語言，所以必須要把高級語言翻譯成機器語言，計算機才能執行高級語言編寫的程序。翻譯的方式有兩種，一個是編譯，一個是解釋。兩種方式只是翻譯的時間不同。編譯型語言寫的程序執行之前，需要一個專門的編譯過程，把程序編譯成為機器語言的文件，比如exe文件，以後要運行的話就不用重新翻譯了，直接使用編譯的結果就行了（exe文件），因為翻譯只做了一次，運行時不需要翻譯，所以編譯型語言的程序執行效率高，但也不能一概而論，部分解釋型語言的解釋器通過在運行時動態優化代碼，甚至能夠使解釋型語言的性能超過編譯型語言。解釋則不同，解釋性語言的程序不需要編譯，省了道工序，解釋性語言在運行程序的時候才翻譯，比如解釋性basic語言，專門有一個解釋器能夠直接執行basic程序，每個語句都是執行的時候才翻譯。這樣解釋性語言每執行一次就要翻譯一次，效率比較低。解釋是一句一句的翻譯。編譯型與解釋型，兩者各有利弊。前者由於程序執行速度快，同等條件下對系統要求較低，因此像開發操作系統、大型應用程序、資料庫系統等時都採用它，像C/C++、Pascal/Object Pascal（Delphi）等都是編譯語言，而一些網頁腳本、伺服器腳本及輔助開發介面這樣的對速度要求不高、對不同系統平台間的兼容性有一定要求的程序則通常使用解釋性語言，如Java、JavaScript、VBScript、Perl、Python、Ruby、MATLAB 等等。但隨著硬體的升級和設計思想的變革，編譯型和解釋型語言越來越籠統，主要體現在一些新興的高級語言上，而解釋型語言的自身特點也使得編譯器廠商願意花費更多成本來優化解釋器，解釋型語言性能超過編譯型語言也是必然的。

④ 如何提高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

⑤ android studio 編譯怎麼提高編譯速度

方法：
1.開啟gradle單獨的守護進程
在下面的目錄下面創建gradle.properties文件：
/home/<username>/.gradle/ (Linux)
/Users/<username>/.gradle/ (Mac)
C:\Users\<username>\.gradle (Windows)
並在文件中增加： org.gradle.daemon=true
同時修改項目下的gradle.properties文件也可以優化。
2.修改android studio配置，在android studio的配置中，開啟offline模式，以及修改配置。實際上的配置和上面的一大段一樣，主要是在這個地方配置的只會在ide構建的時候生效，命令行構建不會生效。

⑥ 如何提高大型工程的編譯速度

影響因素比較多：1文件的大小，文件大小指的是全部include後的大校2文件數量，編譯是一個一個文件進行的，所以你的工程的文件數量也有關系。3還有聲明的復雜程度，復雜聲明需要額外地計算。4最影響編譯速度的估計是C++的模板

⑦ 編譯一段代碼的速度和CPU的線程核心和代碼的速度有關嗎如果編譯一個QQ大小的代碼需要多長時間啊

1cpu的速度跟核心數量有關嗎?是否數量越多就越快呢？只有在同一家族的CPU中進行比較，核心數量、主頻與CPU的運行速度才有正比關系，還有影響的因素是2、3級緩存的大小。核心版本和工藝的升級也有影響。一般在同一家族的CPU中，核心越多、主頻越高、緩存越多、版本越新的CPU越快。比如AMDAthlonIIX2250肯定要比AMDAthlonIIX2240要快，但是不是也一定強於主頻、緩存、核心數都與X2240差不多的IntelPentiumE6300呢？那就不能武斷的說了。需要用各種測試軟體去驗證。2同核心數目，同主頻，同二級緩存哪個快？主板配cpu是看針腳和前端匯流排,和cpu的二級緩存無關,865的主板如果是478介面的,那就支持P42.8E和P43.2C,何況主板和cpu前端匯流排都是800mhz,完美支持兩個比當然是P43.2C好了,雖然P42.8e是1024的二級緩存,但核心是Prescott內核,和A的核心一樣,發熱量大,功耗高,而C的核心是NORTHWOOD核心,比Prescott好

⑧ 程序的編譯速度與程序的執行速度

執行與編譯。。也有掛鉤！。。執行、編譯速度又跟硬體有關！用 WEB來說 第一次編譯比較慢！後面這次訪問就快多了！這跟緩存有關。。還有就是代碼的問題。。 多次的循環判斷也會造成系統執行變慢！。。在提升速度方面 主要就是倆種方法 1.完善的代碼 2.提高硬體了！可能我說的比較片面！別的兄弟可以繼續補充！

⑨ 如何提高android.mk的編譯速度

從eclipse轉到Android studio,總覺得編譯速度或者安裝到手機上的速度會變很快,現實是仍然很慢,所以就搜如何提高build速度,安裝真機上apk能快一點,步驟如下:
1.修改android studio的使用堆內存,根據自己電腦的內存,盡量設置的大一點,點擊help->如下圖:
2.接下來設置使用離線gradle構建,一開始就是使用了內置的默認路徑gradle,勾選offline這個選項,編譯的速度快的不止一點點,在.gradle的離線位置,建立一個gradle.properties的文件,設置精靈後台一直編譯,這樣提高了很多的速度

⑩ 影響vs編譯速度的因素有哪些

影響因素比較多：
1 文件的大小，文件大小指的是全部include展開後的大小。
2 文件數量，編譯是一個一個文件進行的，所以你的工程的文件數量也有關系。
3 還有聲明的復雜程度，復雜聲明需要額外地計算。
4 最影響編譯速度的估計是C++的模板，模板在編譯的時候要進行推導，得到相應的結果，這個非常費時間。如果你是模板里還套了模板，那就比較慢了。
5 鏈接庫的數量，鏈接很多庫也會使得編譯速度變慢。
6 inline函數展開，會使得代碼膨脹，也會影響編譯速度
7 debug模式編譯要留符號表做調試，也會影響速度
8 release模式如果開了優化，編譯優化會改變代碼的某些結構，這也是拖慢編譯器的一個重要因素。