如何提高工程編譯速度
1. 如何提高ios 靜態庫的編譯速度
iPhone何打包通用靜態庫文件(模擬器真機都用)
1.先必須命令：
~/Library目錄lion默認隱藏便用命令使其顯示：
chflags nohidden ~/Library
想再讓其隱藏：
chflags hidden ~/Library
2.靜態庫工程建立：Xcode New新project選擇IOS面Framework&Library面Cocoa Touch Static Library直接next建立MtimeLibrary工程(面功能要關注簡單 2數相加)
?
3.工程建立刪除默認.h .m 文件自創建CountNumbers..h CountNumbers..m文件圖：
4.OK選擇iPhone 5.1Simulator ,Command + B 編譯我Procts面找我編譯模擬器運行libMtimeLibrary.a文件,選擇真機（圖）再編譯真機運行libMtimeLibrary.a庫
?
5. libMtimeLibrary.a 右鍵 Open in Finder找libMtimeLibrary.a所路徑、面我新建項目添加.a文件測試
打終端：輸入命令（路徑根據自決定）
cd /Users/cash/Library/Developer/Xcode/DerivedData/MtimeLibrary-amyqbnwwzcivnyeijggzaorseihj/Build/Procts/
Procts目錄ls 看：
?
再輸入命令： cd Debug-iphonesimulator/
通面命令查看libMtimeLibrary.a信息
命令：lipo -info libMtimeLibrary.a
顯示：
cashmatoMacBook-Pro:Debug-iphonesimulator cash$ lipo -info libMtimeLibrary.a
input file libMtimeLibrary.a is not a fat file
Non-fat file: libMtimeLibrary.a is architecture: i386
i386mac架構
再輸入面命令：
cd ../
cd Debug-iphoneos/
繼續通命令查看 lipo -info libMtimeLibrary.a
顯示：
cashmatoMacBook-Pro:Debug-iphoneos cash$ lipo -info libMtimeLibrary.a
input file libMtimeLibrary.a is not a fat file
Non-fat file: libMtimeLibrary.a is architecture: armv7
armv7iOSjia'ge架構
我明白真機使用能模擬器使用吧
我要做要讓libMtimeLibrary.a文件同i386armv7信息通用靜態庫文件
6. 新建MtimeLibraryDemo應用真機或者模擬器libMtimeLibrary.a CountNumbers.h文件引入進圖：
?
添加CountNumbers.h文件需要調用類面調用libMtimeLibrary.a面
//
// AppDelegate.m
// MtimeLibraryDemo
//
// Created by cash on 12-3-23.
// Copyright (c) 2012 __MyCompanyName__. All rights reserved.
//
#import "AppDelegate.h"
#import "CountNumbers.h"
@implementation AppDelegate
@synthesize window = _window;
- (void)dealloc
{
[_window release];
[super dealloc];
}
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
self.window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
// Override point for customization after application launch.
CountNumbers *cn = [[CountNumbers alloc] init];
int count = [cn addTwoNumbers:10 :20];
NSLog(@"count:%d",count);
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
return YES;
}
7. OK編譯運行應用程序 錯誤篇文檔關鍵.
?
我找剛才真機模擬器libMtimeLibrary.a目錄
debug-iphoneos面基於arm6 arm7編譯庫文件debug-iphonesimulator文件夾面基於i386編譯文件
?
10. 關鍵步驟：
通lipo -create 命令合並2靜態庫文件（-output 面/Users/cash/Desktop/test/libMtimeLibrary.a 合並路徑文件名字）
lipo -create "/Users/cash/Library/Developer/Xcode/DerivedData/MtimeLibrary-amyqbnwwzcivnyeijggzaorseihj/Build/Procts/Debug-iphonesimulator/libMtimeLibrary.a" "/Users/cash/Library/Developer/Xcode/DerivedData/MtimeLibrary-amyqbnwwzcivnyeijggzaorseihj/Build/Procts/Debug-iphoneos/libMtimeLibrary.a" -output "/Users/cash/Desktop/test/libMtimeLibrary.a"
功
通命令 lipo -info libMtimeLibrary.a 知道文件已經i386armv7信息
cashmatoMacBook-Pro:test cash$ lipo -info libMtimeLibrary.a
Architectures in the fat file: libMtimeLibrary.a are: i386 armv7
cashmatoMacBook-Pro:test cash$
w
2. 一個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++一個特性，函數分為聲明和實現兩部分是人所皆知，但類也可以分為前置聲明和定義可能知道的人就比較少了，知道能怎麼用就更少了，其實就是可以用來解決編譯速度問題的。
3. 淺談怎樣加快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++中兩種比較「先進」的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡一下。
4. 大型c++程序中使用類編譯速度慢 怎麼解決
自學很重要，去下網上下幾個類似的程序自己學學再改改吧現在回想以前老師好像也不指望學生能做的多好（畢竟水平在哪裡去了），而是希望通過這種方式培養學生學習的能力和探索精神
5. 如何提高Delphi7的編譯速度
提高 delphi 的編譯速度，最有效的方法是提高計算機的性能（更高的CPU運行速度、使用固態硬碟等）。
從軟體優化的角度來說，有以下做法：
1、減少程序中第三方控制項的引用，尤其是一些冗餘的三方控制項引用要清理掉。
2、優化下操作系統、即時殺毒監控程序等。
3、在編寫代碼時，將 Project->Options->Packages->Build with runtime packages 選項鉤上，生成 exe 最終時再關閉。（詳見網文《delphi的編譯速度提高》）
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. 如何提高linux makefile的編譯速度
-j [N], --jobs[=N] 同時允許 N 個任務；無參數表明允許無限個任務。
最有用的是去掉.o之間的依賴關系檢查，但這樣做需要對自己的工程項目子程序文件非常了解
8. 如何提升vxworks編譯速度
GNU編譯VxWorks已經很快了，因該沒有辦法提升；慶幸吧，你是沒用過WinCE，那個玩意兒整個編譯一遍至少需要30分鍾。
9. 如何提高大型工程的編譯速度
影響因素比較多：1文件的大小，文件大小指的是全部include後的大校2文件數量，編譯是一個一個文件進行的，所以你的工程的文件數量也有關系。3還有聲明的復雜程度，復雜聲明需要額外地計算。4最影響編譯速度的估計是C++的模板