如何解决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).但是能够在没有任何中断的情况下完成构建将会很棒.

我可以影响各个模块的构建顺序吗？这样,我可以将"有问题"的模块放在流程的开头(并希望崩溃不只是转移到其他模块).

BTW:完整的构建大约需要90分钟.

---

更新:

谢谢你的回答.我能够摆脱编译器崩溃并显着减少编译时间.这是我做的:

1. 我从预编译的头文件中删除了所有包含,只是保留了标准的windows/mfc头文件.这迫使我将更多包含添加到其他模块中,但最终所有内容都包含在需要的地方.当然,这一步增加了编译时间,但让我在下一步更有效率.
2. 我安装了ProFactors IncludeManager的试用版.项目详细信息视图可以导出到Excel,可以非常快速地发现预编译头文件中包含的瓶颈和候选项.
3. 大多数编译时间浪费了一些头文件,其中包含一堆其他头文件(包括更多......).我不得不使用前向声明来摆脱一些讨厌的依赖.另外,我将一些类/函数从关键标题中移到了自己的模块中.
4. 在预编译头中放什么？(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 个文件需要那么长时间来编译，那么您就包含了太多不必要的头文件。我猜想人们已经将一堆头文件剪切并粘贴到 CPP 文件中，而没有考虑他们实际需要哪些头文件，以便在不应该包含的时候包含大量的头文件。我还猜测你没有在你应该在的地方提前声明类。

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