c++ - 如何在 Visual Studio 2008 中优化构建速度

Question

有人可以给我一些技巧来提高 Visual Studio 2008 的构建速度吗？
我有一个大型项目，其中包含许多具有完整源代码的模块。每次构建时，都会重新构建每个文件，其中一些没有更改。我可以阻止这些文件被重建吗？我打开了属性“启用最小重建”/Gm，但编译器抛出了这个警告

Command line warning D9030 : '/Gm' is incompatible with multiprocessing; ignoring /MP switch

每个提高构建速度的技巧都会对我有很大帮助。谢谢，

Answer 1

C++ 编译时间对于每个超过一定规模的项目来说都是一场战斗。幸运的是，有这么多人编写大型 C++ 项目，有多种解决方案:

经典的廉价解决方案是“统一构建”。这只是意味着使用 #include 将所有 .cpp 文件放入单个文件中进行编译。 "Unity build"在 stackoverflow 上出现了许多问题，here是我所知道的最突出的一个。这个screencast演示如何在 Visual Studio 中设置这样的构建。

我的理解是，统一构建比经典构建快得多，因为它们有效地缓存了预处理器和链接器完成的工作。统一构建的一个缺点是，如果您触摸一个 cpp 文件，您将不得不重新编译您的“大”cpp 文件。您可以通过将您正在迭代的 cpp 文件从统一构建中分离出来并自行编译来解决此问题。

在 Unity 构建之外，以下是我的最佳实践列表:

• 仅在必要时使用 #include，优先使用前向声明
• 使用 pimpl 习惯用法将类实现排除在通常包含的头文件之外。这样做可以让您将成员添加到实现中，而无需进行长时间的重新编译
• 对通常包含的很少更改的头文件使用预编译头文件 (pch)
• 确保您的构建系统使用本地硬件上的所有可用内核
• 尽量减少预处理器必须搜索的目录列表，在 #include 语句中使用精确路径
• 使用 #pragma once 在头文件的顶部而不是 #ifndef __FOO_H #define __FOO_H ... #endif，如果你使用 #ifndef 技巧编译器每次被包含时都必须打开头文件，#pragma once可以让编译器更高效

如果您正在做所有这些(根据我的经验，统一构建将产生最大的影响)，最后一个选项是分布式构建。 distcc是我所知道的最好的免费解决方案，incredibuild是专有的行业标准。我认为分布式计算将是从困惑的 C++ 编译过程中获得出色迭代时间的唯一方法。如果您可以访问相当多的机器(例如 10-20 台)，这完全值得研究。我应该提到，统一构建和分布式构建并不是完全共生的，因为传统编译可以分成比统一构建更小的工作 block 。如果你想去分布式，可能不值得建立一个统一的构建。