如何减少 Visual Studio 非托管代码中的发布构建时间？答案

【问题标题】：How to reduce release build time in visual studio unmanaged code?如何减少 Visual Studio 非托管代码中的发布构建时间？
【发布时间】：2015-03-10 12:24:39
【问题描述】：

我有一个用 C/C++ 编写的控制台应用程序。即使优化标志设置为-o3，通常也需要 5-10 分钟才能在非 Windows 平台上编译。但是在 Windows 平台上编译需要大约 1-2 小时在 Visual Studio 中将优化标志设置为 Full Optimization (/Ox) 并且将内联函数扩展设置为 Any Suitable (/Ob2)。这在发布/调试模式下都会发生。

我了解编译器正在尝试优化代码，因此它肯定会花费更多时间，但与非 Windows 平台上的其他编译器（主要是 g++）所花费的时间相比，它不是太多时间。

到目前为止我试过了..

从源文件和头文件中删除了不必要的头文件，尽可能地引入前向声明，但没有喘息的机会。

我分析了所有的头文件。项目中约 50 个头文件中的 2-3 个头文件几乎不使用模板。这些头文件也没有广泛包含在源文件中。

我对这种行为有两个观察结果 -

源代码中没有什么严重的错误，否则非 Windows 平台上的编译器将无法如此快速地完成。
似乎 VS 编译器确实需要更多时间（1-2 小时），而其他编译器能够在（10 分钟）内完成，但 VS 编译器不会那么糟糕。因此，我必须改变一些配置（除了优化）。

有谁知道如何找出这里出了什么问题？可能的起点是确定每个文件所花费的编译时间。如何找到每个文件的编译时间？

如果我仍然可以改进/尝试某些东西，是否有可能？

这里是一些 cmets 要求的有关硬件、源代码等的其他详细信息

内存 - 8.0 GB 内存

操作系统 - Windows 7 64 位

处理器 - Intel Core i5 2.6 GHz

Visual Studio - 2013 Ultimate

注意 - 如果我禁用优化 (set /Od and /Ob0 flags in VS)，那么程序在同一台机器上的编译时间不到 5 分钟。

源文件 - 大约 55 个，每个头文件和源文件以及 80KLOC 代码。

【问题讨论】：

请指定以下内容：大约文件数； Windows 机器的相关硬件规格（处理器、RAM）
嗯，这很不寻常。然而，这不是你应该等待的东西。构建发布版本是构建服务器的工作。它只是奴役它，没有人等待它。
是 C 还是 C++ 还是两者的混合？一个可能的问题是其他编译器将 C 编译为 C，而 MSVC 可能将其编译为 C++。 C++ 编译器因要花很长时间编译东西而臭名昭著。
相关The /mp build option
测量每个文件的构建时间的另一种方法：删除所有目标文件 - 构建程序。测量每个目标文件的最后更改时间和创建时间之间的差异（可以使用一些脚本语言来完成）。当您找到罪魁祸首文件时，如果不需要优化，有时在整个文件或某些函数上创建 #pragma optimize ("g", off) 会有所帮助。

标签： c++ c windows visual-studio optimization

【解决方案1】：

有谁知道从哪里开始找出这里出了什么问题？

并非没有更多细节。

如果我仍然可以改进/尝试某些东西，是否有可能？

是的。特别要考虑：

从头文件（包括和定义在 .h 文件中）中删除任何模板化代码，并通过 pimpl 访问该代码（因为模板在每次传递时都会重新评估）。
优化预编译头文件的使用
将您的控制台应用程序拆分为单独的模块（这样您的构建系统只会在构建时更新脏二进制文件）

【讨论】：

我可以知道需要更多详细信息吗？我会尽量提供。
这种延迟可能大部分是由单个依赖项引起的（例如，几乎无处不在的大型模板类），但如果是这种情况，从您提供的信息；也有可能是外部因素限制了对源代码的访问（例如通过网络共享访问的某些文件）；另外，请参阅我的评论（文件数、文件的大致大小等）。
我在编辑2中提到了这个信息。没有文件是通过网络共享访问的。它所依赖的库存在于本地机器上。如果是这种情况，那么在关闭优化标志的情况下将需要相同的时间。

【解决方案2】：

根据 cmets 收到的建议，我首先找出每个文件所花费的编译时间：

清理项目以确保删除所有 *.obj 文件
再次构建项目
注意到每个文件的时间戳，我发现一个文件是编译需要将近两个小时。

当我打开源文件时，我发现代码中有一些与我的观察相反的严重错误。这是一个27KLOC的巨大怪物文件（Opps！，当然我没有写这个文件）。有 739 个类的实例动态创建并分配给一个数组。每个实例也依次动态创建它的一些成员。简而言之，在这个文件中创建了数千个对象。

为了确保这个文件是罪魁祸首，VS Studio 对这个文件进行了太多优化。我禁用了优化在这个文件中由@Predelnik 在 cmets 中提出。瞧！程序现在在几分钟内编译。此源代码需要认真重构。

如果有人遇到这样的问题，我会按照以下方式进行 -

启用 Build-And-Run 选项和 /MP 标志。正如Here 所讨论的那样。如果代码有问题，并行项目和文件编译将无济于事。
找出是否有任何源文件是上述罪魁祸首。我相信我找到的链接Here 是一种计算构建时间而不是每个文件的编译时间的方法。

【讨论】：