編譯時間加速

A. 如何加快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實現端到端的應用性能分析。幫助用戶提高發現應用問題的速度。並且可以深入到代碼級進行應用性能問題剖析，通過可視化界面展示智能移動終端的實時運行狀態。

B. 淺談怎樣加快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. 程序編譯總要很長時間，怎麼提高效率

採用模塊化開發, 不開發的就不引用, 這樣可大大加快編譯速度.

我們項目目前約70W行代碼, 純AS, 但開發各司其職, 最後統一builder

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

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

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

F. 有什麼辦法可以加速make的編譯耗時，以利用到底層的多核硬體

在使用 makefile 工具對多個源程序進行編譯、連接時，首先必須要確保你需要編譯的程序都是正確的，然後將編譯各個源程序按照一定的先後順序寫入到一個 makefile 文件中（預設名稱叫 makefile，但是也可以使用別的文件名），在此編譯過程中，到底哪一個源程序是只編譯、不連接；
哪一個源程序是需要等別的源程序都編譯好了之後，再進行最後的連接，這些都必須寫清楚。

G. 如何提高Keil4的編譯速度

沒有必要提高Keil4的編譯速度，短小程序的編譯也就是點下滑鼠的功夫就完成了。
稍長一些程序，編譯也不過幾秒的事。也不是需要幾十分鍾，想提高速度。
如果程序真的很長，編譯就需要一點時間的，這提高不了速度。要提高速度，只能在寫程序時，盡量優化吧。
如果你的電腦編譯的時間很長的話，還是查一個系統的問題吧。

H. 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（）之前才能調用它

I. 如何加快XCode編譯速度

您好，很高興為您解答。先將此開源軟體配置、編譯、安裝成功，然後加入xcode工程中，編譯，然後慢慢改錯。如果我的回答對您有幫助希望您可以採納，謝謝!如果有什麼不懂的可以追問，以後有什麼問題可以向我提問或者向我的團隊提問。贈人玫瑰，手有餘香！幫助別人，快樂自己！

J. 如何使用 CCache 進行 Cocos2d-x 編譯加速

CCache是C/C++的編譯器緩存。當相同的編譯被再次編譯時，進行檢測並通過之前編譯的緩存進行編譯加速。所以我們可以通過這種方法給Cocos2d-x Android的編譯加速。使用這種方法，在i7 CPU的Macbook Pro Retina上編譯，我們的Cocos2d-x Android工程編譯時間可以從10分鍾減少到30秒！！

注意：以下操作僅對Mac OS X有效。

安裝
我們使用homebrew：
brew install --HEAD ccache

或者通過源碼安裝：
git clone https://github.com/jrosdahl/ccache.git cd ccache ./autogen.sh ./configure make make install cp /usr/local/bin/ccache /usr/bin/

注意：默認的安裝路徑是 /usr/local/bin，我們需要拷貝ccache到/usr/bin/，不然ndk-build會找不到並報錯

如果終端報錯說找不到autoheader，這說明我們需要先安裝automake：

brew install automake

但是，如果如果報錯是說找不到brew，我們就必須先安裝brew：
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

確保ccache的路徑可以被$PATH識別，運行命令：
ccache

如果你看到幫助信息，恭喜你，安裝成功了！

在android上配置編譯環境
我們必須先設置以下環境變數來使用ccache：

vim ~/.bash_profile Add following lines: export USE_CCACHE=1 export NDK_CCACHE=/usr/local/bin/ccache

運行命令行：

ccache -M 10G

這個命令將緩存大小設置為10G。當然，如果你的硬碟有足夠的空間，你也可以將此設置為50G。

然後，我們跳轉到NDK目錄，如果你忘了這個路徑，你可以使用以下命令來查看：
which ndk-build

以下是我的輸出結果：
/developer/android/android-ndk-r9b/ndk-build

所以，我的NDK_ROOT是：

/developer/android/android-ndk-r9b

打開文件：$NDK_ROOT/build/core/default-build-commands.mk

找到以下章節並加入ccache，如下：

ifneq ($(findstring ccc-analyzer,$(CC)),) TARGET_CC = $(CC) else TARGET_CC = ccache $(TOOLCHAIN_PREFIX)gcc #Add ccache support endif TARGET_CFLAGS = TARGET_CONLYFLAGS = ifneq ($(findstring c++-analyzer,$(CXX)),) TARGET_CXX = $(CXX) else TARGET_CXX = ccache $(TOOLCHAIN_PREFIX)g++ #Add ccache support endif TARGET_CXXFLAGS = $(TARGET_CFLAGS) -fno-exceptions -fno-rtti

編譯cocos2d-x游戲
選擇cocos2d-x根目錄，運行：
python build/android-build.py -p 10 cpp-tests

新建一個終端窗口，運行：

ccache -s

這個命令會列印出ccache狀態，如下：

cache directory /Users/heliclei/.ccache primary config /Users/heliclei/.ccache/ccache.conf secondary config (readonly) /usr/local/etc/ccache.conf cache hit (direct) 13588 cache hit (preprocessed) 11145 cache miss 696 called for link 1 called for preprocessing 14 preprocessor error 1 can't use precompiled header 129 no input file 5 files in cache 32222 cache size 5.4 GB max cache size 30.0 GB

如果緩存的高速緩存命中（cache hit）和緩存大小（cache size）均為0，這就表示ccache沒有運行，我們必須從新檢查配置。

在Xcode中部署
配置Xcode（5.1）的ccache環境有點麻煩。我確實能調用ccache，但貌似沒有增加編譯速度。如果你有好的方法解決這個問題，請到github上為本篇教程提交pr！不過我們還是看看設置方法：

首先，我們添加2個自定義宏（user-defined macros）到cocos2d_libs的編譯選項中：

CC=$(SOURCE_ROOT)/../tools/xcode_ccache_wrapper LDPLUSPLUS=$(DT_TOOLCHAIN_DIR)/usr/bin/clang++

然後，我們需要在$(COCOS2dX_ROOT)/tools/路徑下創建名為xcode_ccache_wrapper的腳本：

#!/bin/bash export CCACHE_CPP2=yes export CCACHE_LOGFILE=~/Desktop/ccache.log exec /usr/local/bin/ccache /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Qunused-arguments "$@"

設置完成，我們就可以快樂的在Xcode中編譯了！

打開ccache.log可以查看cache工作狀態。

但問題是，添加cache後，我mbp的Xcocde依舊沒有提升編譯速度。有可能是我使用的腳本不正確，所以，如果你看到本章節，並知道我的問題出在哪，請到github中提交pr，修正我的錯誤，並造福廣發開發者哦！！