如何减少 visual studio 非托管代码中的发布构建时间？
How to reduce release build time in visual studio unmanaged code?
我有一个用 C/C++ 编写的控制台应用程序。通常需要 5-10 分钟才能在 non-windows 平台上编译，即使优化标志设置为 -o3。但是当优化标志设置为 Full Optimization (/Ox) 并且内联函数扩展设置为 Any Suitable (/Ob2)[=55= 时，在 Windows 平台 上编译大约需要 1-2 小时] 在 visual studio。这在 release/debug 模式下都会发生。
我知道编译器正在尝试优化代码，因此它肯定会花费更多时间，但与 non-windows 平台上其他编译器（主要是 g++）所花费的时间相比，这不是太多时间吗。
到目前为止我试过了..
从源代码和 header 文件中删除了不必要的 headers，尽可能引入前向声明，但没有喘息的机会。
我分析了所有 header 个文件。在项目中的 ~50 header 个文件中，有 2-3 header 个文件几乎没有使用模板。这些 header 也没有广泛包含在源文件中。
我对此行为有两个观察结果 -
源代码中没有什么严重错误，否则 non-windows 平台上的编译器将无法如此快速地完成。
似乎 VS 编译器确实需要更多时间（1-2 小时），而其他编译器可以在（10 分钟）内完成，但 VS 编译器不会那么糟糕。因此，我必须缺少更改某些配置（除了优化）。
有谁知道如何找出这里出了什么问题吗？起点可能是确定每个文件所花费的编译时间。如何找到每个文件的编译时间？
如果我还能improve/try有没有可能？
这里是一些评论中要求的关于硬件、源代码等的额外细节
内存 - 8.0 GB 内存
OS - Windows 7 64 位
处理器 - 英特尔酷睿 i5 2.6 GHz
Visual Studio - 2013 终极版
注意 - 如果我禁用优化 (set /Od and /Ob0 flags in VS)，则程序在同一台机器上编译不到 5 分钟。
源文件 - 大约 55 个，header 每个源文件和 80KLOC 代码。
Does anyone has idea where to start to find out what is going wrong here ?
不是没有更多细节。
Could there be possibility if I can still improve/try something ?
是的。特别是，考虑：
从 header 文件中删除任何模板化代码（包括并定义在 .h 文件中），并通过 pimpl 访问该代码（因为每次通过都会重新评估模板）。
优化预编译 headers
将您的控制台应用程序拆分为单独的模块（因此您的构建系统只会在构建时更新脏二进制文件）
根据评论中收到的建议，我开始找出每个文件所用的编译时间：
- 清理项目以确保删除所有 *.obj 文件
- 再次构建项目
- 注意到每个文件的时间戳，我找到了一个文件
花了将近两个小时来编译。
当我打开源文件时，我发现代码中有严重错误，这与我观察到的完全不同。这是一个27KLOC的巨大怪物文件（Opps！，当然我没有写这个文件）。
有 739 个 class 动态创建并分配给数组的实例。每个实例也动态地创建它的一些成员。简而言之，在此文件中创建了数千个对象。
为确保此文件是罪魁祸首，VS studio 对该文件进行了过多优化。我禁用了优化
在此文件中，由@Predelnik 在评论中提出。瞧！程序现在可以在几分钟内编译。此源代码需要认真重构。
如果有人遇到这样的问题，我会按照以下步骤进行 -
启用 Build-And-运行 选项和 /MP 标志。正如所讨论的 Here。如果代码有问题，并行项目和文件编译将无济于事。
找出是否有任何源文件是上述问题的罪魁祸首。我相信 link 我发现 Here 是一种计算每个文件的构建时间而不是编译时间的方法。
我有一个用 C/C++ 编写的控制台应用程序。通常需要 5-10 分钟才能在 non-windows 平台上编译，即使优化标志设置为 -o3。但是当优化标志设置为 Full Optimization (/Ox) 并且内联函数扩展设置为 Any Suitable (/Ob2)[=55= 时，在 Windows 平台 上编译大约需要 1-2 小时] 在 visual studio。这在 release/debug 模式下都会发生。
我知道编译器正在尝试优化代码，因此它肯定会花费更多时间，但与 non-windows 平台上其他编译器（主要是 g++）所花费的时间相比，这不是太多时间吗。
到目前为止我试过了..
从源代码和 header 文件中删除了不必要的 headers，尽可能引入前向声明，但没有喘息的机会。
我分析了所有 header 个文件。在项目中的 ~50 header 个文件中，有 2-3 header 个文件几乎没有使用模板。这些 header 也没有广泛包含在源文件中。
我对此行为有两个观察结果 -
源代码中没有什么严重错误，否则 non-windows 平台上的编译器将无法如此快速地完成。
似乎 VS 编译器确实需要更多时间（1-2 小时），而其他编译器可以在（10 分钟）内完成，但 VS 编译器不会那么糟糕。因此，我必须缺少更改某些配置（除了优化）。
有谁知道如何找出这里出了什么问题吗？起点可能是确定每个文件所花费的编译时间。如何找到每个文件的编译时间？
如果我还能improve/try有没有可能？
这里是一些评论中要求的关于硬件、源代码等的额外细节
内存 - 8.0 GB 内存
OS - Windows 7 64 位
处理器 - 英特尔酷睿 i5 2.6 GHz
Visual Studio - 2013 终极版
注意 - 如果我禁用优化 (set /Od and /Ob0 flags in VS)，则程序在同一台机器上编译不到 5 分钟。
源文件 - 大约 55 个，header 每个源文件和 80KLOC 代码。
Does anyone has idea where to start to find out what is going wrong here ?
不是没有更多细节。
Could there be possibility if I can still improve/try something ?
是的。特别是，考虑：
从 header 文件中删除任何模板化代码（包括并定义在 .h 文件中），并通过 pimpl 访问该代码（因为每次通过都会重新评估模板）。
优化预编译 headers
的使用
将您的控制台应用程序拆分为单独的模块（因此您的构建系统只会在构建时更新脏二进制文件）
根据评论中收到的建议，我开始找出每个文件所用的编译时间：
- 清理项目以确保删除所有 *.obj 文件
- 再次构建项目
- 注意到每个文件的时间戳，我找到了一个文件 花了将近两个小时来编译。
当我打开源文件时，我发现代码中有严重错误，这与我观察到的完全不同。这是一个27KLOC的巨大怪物文件（Opps！，当然我没有写这个文件）。 有 739 个 class 动态创建并分配给数组的实例。每个实例也动态地创建它的一些成员。简而言之，在此文件中创建了数千个对象。
为确保此文件是罪魁祸首，VS studio 对该文件进行了过多优化。我禁用了优化 在此文件中，由@Predelnik 在评论中提出。瞧！程序现在可以在几分钟内编译。此源代码需要认真重构。
如果有人遇到这样的问题，我会按照以下步骤进行 -
启用 Build-And-运行 选项和 /MP 标志。正如所讨论的 Here。如果代码有问题，并行项目和文件编译将无济于事。
找出是否有任何源文件是上述问题的罪魁祸首。我相信 link 我发现 Here 是一种计算每个文件的构建时间而不是编译时间的方法。