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（）之前才能调用它。下面的例子说明了这一点：
//
declaration or prototype for B
void B();
void A()
{
B();
}
// definition, or function body of B
void B()
{
cout << "hello";
}
没有B（）的原型，这个代码不会编译通过的，除非函数B（）的函数体移到函数A（）之前。
对于编译器来说，函数的原型很重要。当你运行程序时，编译器都要插入恰当的代码来调用程序。编译器必需知道要有多少个参数传给函数。也要知道函数的参数应该在栈里还是在寄存器里。总而言这，编译器必需知道怎么来产生正确的代码来调用这个函数，这就要求编译器必需知道预先声明或定义了的被调用的函数。
为使函数或类的原型简单化，C＋＋提供了一个＃include 指令。＃include代表允许源文件在函数原型被调用的位置之前包含的一个头文件中找到函数原型。＃include 指令在win32C++编程中很重要。C RTL函数的原型都包含在标准的头文件集中。win32API的原型全在微软提供的头文件集中，VCL中的类和函数的在原型则在随C＋＋builder发行的头文件中。没有这些，你几乎做不了什么。
头文件提供了一种让程序员很容易管理的方式来执行C＋＋的类型检查，但是也带来了很大的代价。当编译器运行到一个#include 指令时，它会打开这个头文件并插入到当前文件中，然后编译器象分析已编译的文件一样来分析这些包含进来的文件。当被包含的文件中还包含有其它的头文件时会怎么样呢？编译器仍会插入那个文件再分析它，想象一下，当10、20甚至100个文件被包含时呢？尽管如此数量的包含文件听起来很多，但当你加入window sdk头文件和所有vcl头文件时，这并不是不可能的。
来举个例子说明一下编译器是如何展开和翻译被包含的文件的。这是一个我用console wizard建立的一个简单的控制台程序。为了试验代码，在options-project-compiler在把pre-compiled headers选项关掉。
//
include some standard header files
//包含了一些标准的头文件
#include <stdio.h>
#include <string.h>
#include <iostream.h>
#include <Windows.h>
#pragma hdrstop
#include <condefs.h>
//-----------------------------------------------
int main()
{
printf("Hello from printf.\n");
cout << "Hello from cout" << endl;
MessageBeep(0);
return 0;
}
当用C++builder编译工程时，编译进度对话框显示工程中包含有130,000行代码。13万行！怎么回事？源文件中只有大约四行代码，这13万行都包含在stdio.h,string.h,iostream.h,Windows.h和被这四个头文件所包含的头文件里。
好，现在来看一下当工程中包含多个cpp文件时情况是怎么样的。停止编译这个工程，再加一个已有的文件到这个工程中。在第二个文件中加一个简单的函数。再到第一个文件中来调用这个新函数。
//-------------------------------------------------------
// UNIT1.CPP
#include <stdio.h>
#include <string.h>
#include <iostream.h>
#include <Windows.h>
#include "Unit1.h" // prototype A() in unit1.h
#pragma hdrstop
void A()
{
printf("Hello from function A.\n");
}
//-------------------------------------------------------
//-------------------------------------------------------
// PROJECT1.cpp
#include <stdio.h>
#include <string.h>
#include <iostream.h>
#include <windows.h>
#include "Unit1.h"
#pragma hdrstop
#include <condefs.h>
//-------------------------------------------------------
USEUNIT("Unit1.cpp");
//-------------------------------------------------------
int main()
{
printf("Hello from printf.\n");
cout << "Hello from cout" << endl;
A();
MessageBeep(0);
return 0;
}
//-------------------------------------------------------
好，现在再来编译这个工程。如果在编译之前你关掉了pre-compiled头文件选项，当你编译完时你会发现编译进度对话框显示共有260，000行代码。可以看到，编译器不得不把两个文件都包含的相同的头文件集都做处理。在前面的例子里，编译器多处理了这些头文件带来的13万行代码。第二个文件又让编译器处理了同样的13万行代码，总共26万行。不难想象在一个大工程里行数将会以什么速度增长。一遍又一遍的处理这些相同的头文件大大的增加了编译的时间。
C++Builder是如何通过预编译头文件的方法来减少编译时间的
Borland的工程师认识到可以设计一个不用一遍又一遍处理同样的头文件的编译器来减少编译时间。于是Borland c++3.0中引入了预编译头文件的概念。处理方法很简单，当编译器处理源文件中的一组头文件时，把编译好的映象文件保存在磁盘上，当其它的源文件是引用同样的一组头文件时编译器直接读取编译好的文件而不是再一次分析。
修改一下刚才的控制台程序来看看预编译头文件是如何减少编译时间的。代码本身不用修改，仅仅把工程选项中的预编译头文件选项再选中就行了。选择Options-Project-Compiler并选中Use pre-compiled headers或是Cache pre-compiled headers。在预编译头文件名一栏中填入PCH.CSM。改好之后从重编译工程。
编译过程中注意一下编译进度对话框。你会发现当编译器编译project1.cpp时要处理130，000行代码，而编译UNIT1.cpp时只处理20行代码。当编译器分析第一个源文件时产生了一个预见编译头文件的映象，在处理第二个文件时直接用来提高编译速度。可以想象当源文件的数目不是2而是50时，性能会提高多少！
VCL GUI工程中预编译头文件的说明
通过预编译头文件的方法，上一个示例起码减少了50%的编译时间。而这不过仅仅是一个没什么功能的简单的控制台程序而已。你也会到在VCLGUI程序中会怎么样呢？缺省情况下，c++builder自动打开工程的预编译头文件选项的。但它仅仅对vcl.h文件进行预处理，这个头文件可以在任何一个窗体的源文件顶端找到。
#include <VCl.h>
#pragma hdrstop
#pragma hdrstop指令通知编译器停止产生预编译映象。在hdrstop指令之前的#include语句会被预编译，之后的就不会了。
那当vcl.h被预编译时到底有多少头文件也被预编译了呢？可以查看一下vcl.h，看到它包含了另一个叫做vcl0.h的头文件。如果你没有更改C++builder的缺省设置，vcl0.h就包含了一小组vcl的头文件，它们是：
//
Core (minimal) VCL headers
//
#include <sysdefs.h>
#include <system.hpp>
#include <Windows.hpp>
#include <messages.hpp>
#include <sysutils.hpp>
#include <classes.hpp>
#include <graphics.hpp>
#include <controls.hpp>
#include <forms.hpp>
#include <dialogs.hpp >
#include <stdctrls.hpp>
#include <extctrls.hpp>
这是一小部分常被重复包含的头文件，也许它只是大中型工程常用到的头文件的一个了集。vcl0.h还允许你通过定义条件（#define)来预编译更多的头文件。你可以通过#define一个叫做INC_VCLDB_HEADERS的变量来预编译数据库的头文件。同样，还可以定义INC_VCLEXT_HEADERS来预编译c++builder的扩展控件（Extra
controls)。如果你还定义了INC＿OLE＿HEADERS，C++builder还会预编译一些SDK COM的头文件。这些定义要放在#include vcl.h语句这前。
#define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS
#include <vcl.h>
#pragma hdrstop
注意：如果你要使用这些功能的话，你要确保把这两个#define加到每个cpp文件，即使是没有用到数据库或是扩展控件的文件。至于原因稍后会被讲到。
使用预编译头文件来优化C++builder。
缺省的预编译头文件设置确实减少了编译工程的时间。你可以通过打开和关闭观预编译头文件选项时完全编译一个大工程所要用的时间来证明这一点。本节的目的就是通过改善预编译头文件的方法来进一步减少编译时间。这里我要讲到两个技术。
在讨论这两个技术之前呢，有必要了解一下c++builder在编译源程序时是怎样来决定是否使用已存在的预编译的头文件的映象的。c++builder会给你工程中的每一个源文件都产生一个唯一的预编译头文件映象。这些映象被保存在硬盘上的一个文件里。编译器会在有两个源文件使用同样的预编译头文件映象时来重用一个映象文件。这是很重要的一点，两个源文件包含了完全一样的头文件时就会使用预编译头文件映象。再有就是他们包含这些头文件的顺序必需相同。简单的说：源文件的#pragma
hdrstop指令之前必需完全相同。下面是一些例子：
示例1：预编译头文件映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #include <iostream.h>
#pragma hdrstop #pragma hdrstop
示例2：预编译头文件映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #include <stdio.h>
#include <iostream.h> #pragma hdrstop
#pragma hdrstop
示例3：预编译头文件映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #pragma hdrstop
#pragma hdrstop #include <stdio.h>
示例4：预编译映象匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #include <stdio.h>
#include <string.h> #include <string.h>
#include <iostream.h> #include <iostream.h>
#include <Windows.h> #include <Windows.h>
#include "unit1.h" #include "unit1.h"
#pragma hdrstop #pragma hdrstop
示例5：预编译映象匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#define INC_VCLDB_HEADERS #define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS #define INC_VCLEXT_HEADERS
#include <vcl.h> #include <vcl.h>
#pragma hdrstop #pragma hdrstop
#include "unit1.h" #include "unit2.h"
示例6：预编译映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#define INC_VCLDB_HEADERS #include <vcl.h>
#define INC_VCLEXT_HEADERS #pragma hdrstop
#include <vcl.h>
#pragma hdrstop
当编译器处理一个预编译映象不匹配的源文件时就会重新再产生一个全新的映象。看上面的示例2。尽管stdio.h在unit1.cpp中已经被编译过了，但是unit2中还是要被编译的。只有在多个文件中都能用到预编译映象编译器才能减少编译的时间。
这就是我所讲到的技术的基础。预编译尽可能多的头文件，并确保在每个源文件中都用到同样的预编译映象。
技术1：
第一个技术只是通过在每个源文件中定义两个条件来增加vcl.h中包含的头文件的数目。打开工程中的每个cpp文件包括工程文件，象下面看到的那样改变它们的头两行。
#define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS
#include <vcl.h>
#pragma hdrstop
如果你不喜欢这种方法，你可以在Project-Options-Directories/Conditional条件定义栏中填入INC＿VCLDB＿HEADERS 和 INC＋VCLEXT＿HEADERS来达到同样的目的。
或许你也想插入一些Windows.h之类的你常用的C RTL头文件，要确保插入到hdrstop pragma之前，而且顺序要相同。
#define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS
#include <vcl.h>
#include <Windows.h>
#include <stdio.h>
#pragma hdrstop
技术2：
技术1的效果很好，但它不是很灵活。如果你想要在观感编译的头文件列表中再加入一个新的头文件的话，你要修改你工程中的每一个源文件。此外，技术一容易出错。如果你把包含的顺序弄乱了，你只会更糟而不是更好。
技术二处理了技术一的一些缺点。方法就是创建一个巨大的头文件来包含你工程中用到的所有的头文件。这个头文件将包含有VCL的头文件、window SDK的头文件以及RTL头文件。当然你也可以包含一些创建的窗体的头文件，但稍会你会了解到不应该把一些常修改的文件做预编译处理（查看注意事项：不要预编译变化的头文件）
下面就样一个文件的示例：
//---------------------------------------------------------
// PCH.H: Common header file
#ifndef PCH_H
#define PCH_H
// include every VCL header that we use
// could include vcl.h instead
#include <Buttons.hpp>
#include <Classes.hpp>
#include <ComCtrls.hpp>
#include <Controls.hpp>
#include <ExtCtrls.hpp>
#include <Forms.hpp>
#include <Graphics.hpp>
#include <ToolWin.hpp>
// include the C RTL headers that we use
#include <string.h>
#include <iostream.h>
#include <stdio.h>
// include headers for the 3rd party controls
// TurboPower System
#include "StBase.hpp"
#include "StVInfo.hpp"
// Our custom controls
#include "DBDatePicker.h"
#include "DBRuleCombo.h"
#include "DBPhonePanel.h"
// Object Repository header files
#include "BaseData.h"
#include "BASEDLG.h"
// project include files
// pre-compile these only if PRECOMPILE_ALL is defined
#ifdef PRECOMPILE_ALL
通过预编译头文件的方法来提高C++builder的编译速度
参考：http://www.xuebuyuan.com/1539949.html