我正在一个buildbot上编译两个C++项目，每次提交都要编译。这两个项目分别有约1000个文件，一个有100 kloc，另一个有170 kloc。从gcc（4.4）到Visual C++（2008），编译时间差异很大。
对于其中一个项目的Visual C++编译需要20分钟。由于一个项目依赖于另一个项目，因此无法利用多个核心。最终，在Debug和Release，32位和64位下，两个项目的全部8个版本都要花费超过2个半小时来完成编译。
而对于其中一个项目的gcc编译只需要4分钟。它可以在4个核心上并行处理，并且大约需要1分10秒的时间。四个版本（Debug/Release，32/64位）的两个项目的所有8个构建都可以在不到10分钟内编译完成。
Visual C++编译时间为什么会这么慢？它们的速度基本上是慢了5倍。
在编译C++ kloc时可以期望的平均时间是多少？我的vc++为7 s/kloc，而gcc为1.4 s/kloc。
在Visual C++上，有什么方法可以加快编译时间吗？
VC++编译器减速的一个原因是，如果您有一个头文件来初始化非平凡const值类型的具体实例。您可能会看到这种情况发生在std::string或GUID类型的常量中。它影响编译和链接时间。
对于单个dll，这导致了10倍的减速。如果将它们放在预编译头文件中，或者只在头文件中声明并在cpp文件中初始化，可以帮助解决问题。
确保检查病毒扫描程序，并尝试使用预编译头文件，否则您将无法看到VC++的最佳表现。
还要确保%TMP%文件夹与构建写入的分区相同，因为VC++会创建临时文件并稍后移动它们。
const。我会进行编辑。我没有编写这段代码。我通过提前声明名称并在cpp文件中初始化来修复它们。 - user180326互相依赖的项目并不意味着不能进行并行处理。构建系统足够智能，可以找出并避免关键依赖性，否则gcc就无法使用4个内核。
所以（除了其他措施之外），为什么不尝试在Visual Studio中启用多进程处理，使用/MP选项（请参见http://msdn.microsoft.com/en-us/library/bb385193.aspx）。
/FI 标志，我会给予加分。但我并不是 #pragma hdrstop 的忠实粉丝。 - Manuel#pragma hdrstop？它是一种非常方便的方式，可以允许干净的最小依赖构建，无需预编译，以及使用预编译头文件进行快速构建，这是我认为确保代码仅包含所需内容的绝佳方式，使其更易于重用... - Len Holgate#pragma hdrstop 允许更精细地调整需要放入预编译头文件的内容和可以包含在C++文件中的内容，相较于使用 /FI 方法，它的使用方式略微更加明显。 - Len Holgate虽然这不是问题的直接回答，但我们公司正在使用IncrediBuild进行分布式编译。它真的可以加速编译过程。 http://incredibuild.com/visual_studio.htm
约翰·拉科斯的《大规模C++软件设计》一书包含许多有关为大型项目构建代码和设计的技巧，其中包括许多加快编译速度的技巧。虽然与Visual C++没有直接关系，但无论如何阅读都是值得的。
可能存在依赖检查问题，除非您强制进行完全重建。
您可以创建一些静态库。将很少更改的代码放入库中。
构建程序最慢的部分：
通常情况下，链接和可执行文件创建阶段是最快的。
您确定了吗：
请记住，在确定效率时，始终以某种方式进行分析。
你是在同一台机器上构建吗？你使用的是相同的操作系统吗？我曾经看到过在比较Cygwin中的GCC和运行在Windows主机内部的VirtualBox机器中的GCC时，速度差异在3-10倍左右。
看起来非常奇怪，为什么会有这样的差异...但您也可以利用Visual上的多核心！
基本上，您有4种编译模式：（Debug / Release）x（32位/64位），每个模式都是完全独立的，您可以完美地并行运行这4个模式，充分利用可用的4个核。或者在Visual Studio上尝试MultiProcessor方法。
但这还不够。 150分钟对比10分钟是一个巨大的差距。从我的个人经验来看，在减少编译时间方面有两个主要因素：