如何解决Visual Studio编译器崩溃

Question

我们有一个大型Visual Studio 2005 C ++ / Mfc解决方案，1个项目包含大约1300个源文件（因此大约有650.h和650个.cpp文件）。我们还使用Boost和其他一些库（COM：MSXML，Office）。

最近，我添加了一些boost :: multi_index实例来加快速度。这一切都在大部分时间汇编。但是现在，当我正在进行完整（发布）重建时，我会在几个模块上遇到编译器崩溃。

Fatal Error C1060: "compiler is out of heap space"

我已经尝试在预编译的头文件中减少包含（删除了除标准MFC头之外的所有内容）。另外，我删除了编译器选项/ Zm200（我们在编译预编译头文件之前需要它）。

奇怪的是：当我在编译器崩溃后按F7（build）时，构建过程继续没有任何问题（或者至少在下一次编译器崩溃时再次按F7）。但是能够在没有任何中断的情况下完成构建将会很棒。

我可以影响各个模块的构建顺序吗？这样，我可以将“有问题”的模块放在流程的开头（并希望崩溃不只是转移到其他模块）。

顺便说一句：完整的构建需要大约90分钟。

---

更新

感谢您的回答。我能够摆脱编译器崩溃并显着减少编译时间。这是我做的：

1. 我从预编译的头文件中删除了所有包含，只是保留了标准的windows / mfc标头。这迫使我将更多包含添加到其他模块中，但最终所有内容都包含在需要的地方。当然，这一步增加了编译时间，但让我在下一步更有效率。
2. 我安装了ProFactors IncludeManager的试用版。项目详细信息视图可以导出到Excel，可以非常快速地发现预编译头文件中包含的瓶颈和候选项。
3. 大多数编译时间浪费了一些头文件，其中包含一堆其他头文件（其中包括更多......）。我不得不使用前向声明来摆脱一些讨厌的依赖。另外，我将一些类/函数从关键标题中移到了自己的模块中。
4. What to put in precompiled header? (MSVC)帮助我在预编译的头文件中获取了包含权限。我添加了STL，Boost，Windows标题。然后添加了我们自己的（或多或少稳定的，优化的）标头，以及资源头文件。
5. 我重复了第3步和第4步，总是用IncludeManager检查新候选人。
6. 步骤1到5使编译时间（释放模式）下降，从90到大约45分钟。
7. 我禁用了所有内容的浏览信息生成，因为我们似乎没有使用它（我找不到任何有关它真正有用的信息......）。这又打破了构建过程的6分钟。
8. 我将/ MP（多处理器支持）开关添加到C ++编译器命令。现在重建时间缩短到22分钟。这一切都是在一台核心PC上完成的。
9. 我将整个解决方案转移到双核PC上。重建项目需要16分钟。
10. 创建调试版本快5分钟：
    • 单核机器上17分钟，
    • 双核机器上11分钟。

更新2：

上面，我提到“单核机器”，实际上是一个较慢的双核机器。

Answer 1

如果有1300个文件需要很长时间才能编译，那么你将包含太多不必要的头文件。我猜人们已经将一堆headre文件剪切并粘贴到CPP文件中，而没有考虑他们实际需要哪些标题，以便在它们不应该包含它们时加载它们。我也猜测你没有向前宣布你应该去的课程。

我建议你需要花一些时间浏览你的项目并删除不必要的#includes。我怀疑这会解决你的内存不足问题并且会缩短你的编译时间。

Answer 2

我必须同意Goz，看一下this (SO) post，看看如何帮助删除多余的头文件。

我们的C ++解决方案规模很大，过去需要50分钟才能编译，通过仔细的头文件分析，我们可以将其缩短到8分钟。

Answer 3

IncrediBuild（VC ++的分布式构建系统）除了节省时间外还有一个额外的有用功能。如果远程计算机无法返回结果，它将自动重新启动编译。因此，您应该能够在5分钟或10分钟内完成构建，而不会崩溃。