如何提高 Visual C++ 编译时间？

How to improve Visual C++ compilation times?

提问by Didier Trosset

I am compiling 2 C++ projects in a buildbot, on each commit. Both are around 1000 files, one is 100 kloc, the other 170 kloc. Compilation times are very different from gcc (4.4) to Visual C++ (2008).

我在每次提交时在 buildbot 中编译 2 个 C++ 项目。两者都是大约 1000 个文件，一个是 100 kloc，另一个是 170 kloc。编译时间从 gcc (4.4) 到 Visual C++ (2008) 有很大不同。

Visual C++ compilations for one project take in the 20 minutes. They cannot take advantage of the multiple cores because a project depend on the other. In the end, a full compilation of both projects in Debug and Release, in 32 and 64 bits takes more than 2 1/2 hours.

一个项目的 Visual C++ 编译需要 20 分钟。他们无法利用多个核心，因为一个项目依赖于另一个。最后，以 32 位和 64 位对 Debug 和 Release 中的两个项目进行完整编译需要超过 2 1/2 小时。

gcc compilations for one project take in the 4 minutes. It can be parallelized on the 4 cores and takes around 1 min 10 secs. All 8 builds for 4 versions (Debug/Release, 32/64 bits) of the 2 projects are compiled in less than 10 minutes.

一个项目的 gcc 编译需要 4 分钟。它可以在 4 个内核上并行化，大约需要 1 分 10 秒。2 个项目的 4 个版本（调试/发布，32/64 位）的所有 8 个版本都在不到 10 分钟的时间内编译完成。

What is happening with Visual C++ compilation times? They are basically 5 times slower.

Visual C++ 编译时间发生了什么变化？它们基本上慢了 5 倍。

What is the average time that can be expected to compile a C++ kloc? Mine are 7 s/kloc with vc++ and 1.4 s/kloc with gcc.

预计编译 C++ kloc 的平均时间是多少？我的 vc++ 为 7 s/kloc，gcc 为 1.4 s/kloc。

Can anything be done to speed-up compilation times on Visual C++?

有什么办法可以加快 Visual C++ 上的编译时间？

采纳答案by Didier Trosset

One thing that slows down the VC++ compiler is if you have a header file that initializes concrete instances of non-trival constvalue types. You may see this happen with constants of type std::stringor GUIDs. It affects both compilation and link time.

降低 VC++ 编译器速度的一件事是，如果您有一个头文件来初始化非平凡const值类型的具体实例。您可能会在类型常量std::string或 GUID 中看到这种情况。它影响编译和链接时间。

For a single dll, this caused a 10x slowdown. It helps if you put them in a precompiled header file, or, just declare them in a header and initialize them in a cpp file.

对于单个 dll，这会导致 10 倍的速度下降。如果将它们放在预编译的头文件中，或者只是在头文件中声明它们并在 cpp 文件中初始化它们，它会有所帮助。

Do take a look into the virus scanner, and be sure to experiment with precompiled headers, without it you won't see VC++ at its best.

请查看病毒扫描程序，并确保尝试使用预编译的头文件，否则您将看不到 VC++ 的最佳状态。

Oh yeah, and make sure the %TMP% folder is on the same partition as where your build is written to, as VC++ makes temp files and moves them later.

哦，是的，并确保 %TMP% 文件夹与您的构建写入的分区位于同一分区上，因为 VC++ 制作临时文件并稍后移动它们。

回答by jdisk

The projects depending on each other doesn't imply that no parallelization is possible. The build systems are smart enough to figure out and avoid critical depenedancies, Otherwise gcc wouldn't be able to use 4 cores.

相互依赖的项目并不意味着不可能进行并行化。构建系统足够聪明，可以找出并避免关键的依赖关系，否则 gcc 将无法使用 4 个内核。

So (in addition to other steps), why not just try enabling multiprocessing in Visual Studio using /MP (See http://msdn.microsoft.com/en-us/library/bb385193.aspx).

所以（除了其他步骤），为什么不尝试使用 /MP 在 Visual Studio 中启用多处理（请参阅http://msdn.microsoft.com/en-us/library/bb385193.aspx）。

回答by Len Holgate

How are you building the Visual Studio projects? Are you just running the ide (devenv) with the project and /buildor do you have a makefile similar to what I assume you are using for gcc. I'm assuming that both builds use a similar makefile but I thought it worth checking.

你如何构建 Visual Studio 项目？您是否只是在项目中运行 ide (devenv)，/build或者您是否有一个类似于我假设您用于 gcc 的 makefile。我假设两个版本都使用类似的 makefile，但我认为值得检查。

Are you using precompiled headers for either compiler? If you're NOT using precompiled headers for VS then you might like to switch to using them. Personally I'd recommend using the #pragma hdrstopapproach rather than a single all inclusive header file but if you're currently NOT using precompiled headers and want to try it out a single all inclusive header file that is force included (using the /FIcompiler command line switch) can be tested quickly without any code changes.

您是否为任一编译器使用预编译头文件？如果您不使用 VS 的预编译头文件，那么您可能希望切换到使用它们。我个人建议使用该#pragma hdrstop方法而不是单个全包头文件，但如果您当前未使用预编译头文件并想尝试一个强制包含的全包头文件（使用/FI编译器命令行开关）无需任何代码更改即可快速测试。

I wrote about both /FIand #pragma hdrstophere: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html

我写了两个/FI，并#pragma hdrstop在这里： http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html

回答by tommyk

It's not the direct answer for the question but at my company we are using IncrediBuild for distributed compilation. It really speeds up the compilation process. http://incredibuild.com/visual_studio.htm

这不是问题的直接答案，但在我的公司，我们使用 IncrediBuild 进行分布式编译。它确实加快了编译过程。http://incredibuild.com/visual_studio.htm

回答by Hollance

The book "Large-Scale C++ Software Design" by John Lakos has many tips on structuring your code and design for large-scale projects. Including many tips on speeding up compilation. Not directly related to Visual C++, but well worth reading anyway.

John Lakos 所著的“Large-Scale C++ Software Design”一书提供了许多关于为大型项目构建代码和设计的技巧。包括许多加速编译的技巧。与 Visual C++ 没有直接关系，但无论如何都值得一读。

回答by cheind

I've written two articles on techniques that reduce the compilation time. Among these techniques a post on precompiled headerand unity buildsthat may help you improve compilation times. They ship with CMake scripts that handle the techniques transparently.

我写了两篇关于减少编译时间的技术的文章。在这些技术中，有关预编译头文件和统一构建的帖子可能会帮助您缩短编译时间。它们附带 CMake 脚本，可以透明地处理这些技术。

回答by Thomas Matthews

Perhaps there is an issue with the dependency checking, unless you are forcing a complete rebuild.

也许依赖项检查存在问题，除非您强制完全重建。

You could make some static libraries. Put code that seldom changes into libraries.

您可以制作一些静态库。将很少更改的代码放入库中。

The slowest parts of building a program:

构建程序最慢的部分：

1. Opening and closing files.
2. Parsing and translating source files.

1. 打开和关闭文件。
2. 解析和翻译源文件。

In general, the linking and executable creation phases are the fastest.

通常，链接和可执行文件创建阶段是最快的。

Have you determined:

你确定：

1. which phases are the slowest?
2. Which files are slowest to compile?

1. 哪个阶段最慢？
2. 哪些文件编译最慢？

Remember, when determining efficiency, always profile (in one manner or another).

请记住，在确定效率时，请始终进行概要分析（以一种或另一种方式）。

回答by sharptooth

First of all, in most cases you can build debug and release configurations of the same project in parallel.

首先，在大多数情况下，您可以并行构建同一项目的调试和发布配置。

Also what you describe sounds horribly slow - looks like you don't use precompiled headers in VC++ or using them incorrectly - they are specifically intended to improve compilation time.

此外，您所描述的听起来非常慢-看起来您没有在 VC++ 中使用预编译头文件或错误地使用它们-它们专门用于缩短编译时间。

回答by e8johan

Are you building on the same machine? Are you using the same OS? I've seen speed differences in the region of 3-10x when comparing GCC in Cygwin and GCC in a VirtualBox machine running inside the Windows hosting Cygwin.

你是在同一台机器上构建吗？您使用的是相同的操作系统吗？在比较 Cygwin 中的 GCC 和在托管 Cygwin 的 Windows 中运行的 VirtualBox 机器中的 GCC 时，我看到了 3-10 倍的速度差异。

回答by Matthieu M.

It seems very strange that there would be such a difference... but there is no reason that you cannot take advantage of the multicores on Visual either!

会有这样的差异似乎很奇怪……但是您也没有理由不能在 Visual 上利用多核！

Basically you have 4 compilations modes: (Debug/Release)x(32bits/64bits), each one being totally independent of the other, you could perfectly run the 4 in parallel, taking full advantage of the 4 cores available. Or simply try out the MultiProcessor approach on Visual Studio too.

基本上你有 4 种编译模式：(Debug/Release)x(32bits/64bits)，每一个都完全独立于另一个，你可以完美地并行运行 4，充分利用可用的 4 个内核。或者也可以在 Visual Studio 上尝试使用 MultiProcessor 方法。

However that's not going to cut it. 150 minutes versus 10 minutes is a huge gap. From my personal experience there are 2 major factors in reducing compilation time:

然而，这不会削减它。150 分钟和 10 分钟是一个巨大的差距。根据我的个人经验，减少编译时间有两个主要因素：

• have all files used on a local disk (using replication from remote ones if necessary) and all files created locally too (.o .so)
• use all the cores at your disposal, and if you can, even go Multi Machines (distcc etc...)

• 在本地磁盘上使用所有文件（如有必要，使用远程复制）和本地创建的所有文件（.o .so）
• 使用您可以使用的所有内核，如果可以，甚至可以使用多机（distcc 等...）