如何解决Visual Studio Compiler崩溃问题

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

We have a large Visual Studio 2005 C++/Mfc solution, 1 project with around 1300 source files (so about 650 .h and 650 .cpp files). We also use Boost and a few other libraries (COM: MSXML, Office).

最近，我添加了一些boost :: multi_index实例来加快一些事情。这一切都编译大多数时间。但现在，当我做一个完整的（发布）重建，我得到编译器崩溃在几个模块。

Recently, I've added a few instances of boost::multi_index to speed up things a bit. This all compiles most of the time. But now, when I'm doing a full (release) rebuild, I get compiler crashes at a few modules.

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

我已经尝试过减少预编译头文件中的include（除了标准的MFC头文件）。此外，我删除了编译选项/ Zm200（我们需要之前编译预编译头文件）。

I've already tried to reduce includes in the precompiled header file (removed pretty much everything except the standard MFC headers). Also, I've removed the compiler option /Zm200 (which we needed before to compile the precompiled header file).

奇怪的是：当我在编译器崩溃后按F7（build），构建过程会继续，没有任何问题（或者至少下一次编译崩溃，在那里我再次按F7）。但是，能够做一个完整的构建没有任何休息将是很高兴。

The strange thing: when I just press F7 (build) after the compiler crashes, the build process continues without any problems (or at least up to the next compiler crash, where I press F7 again). But it would be nice to be able to do a complete build without any breaks.

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

Can I influence the build order of the individual modules? This way, I could put the "problematic" modules at the beginning of the process (and hope the crashes don't just shift to other modules).

BTW：A完成构建需要大约90分钟。

BTW: A complete build takes around 90 minutes.

更新：

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

Thanks for the answers. I was able to get rid of the compiler crashes and reduce compile time significantly. Here's what I did:

1. 我从预编译头文件中删除了所有的include，只是标准的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. 我把整个解决方案移动到双核电脑。


10. 创建调试版本的速度提高了5分钟：
    
    
    
    
    • 17分钟单核机器
    
    
    • 在双核机器上运行11分钟。
    
    

1. I removed all the includes from the precompiled header file, just the standard windows/mfc headers were left as they were. This forced me to add even more includes into other modules, but in the end everything was included where it was needed. Of course, this step increased compile time, but allowed me to be more efficient in the next step.
2. I installed the trial version of ProFactors IncludeManager. The Project Detail View can be exported to Excel, where bottlenecks and candidates to be included in the precompiled header file can be spotted quite fast.
3. Most compile time was wasted with a few header files that included a heap of other header files (that included some more...). I had to use forward declarations to get rid of some nasty dependencies. Also, I moved some classes / functions out of critical headers into their own modules.
4. What to put in precompiled header? (MSVC) helped me getting the includes in the precompiled header file right. I've added STL, Boost, Windows headers. then added our own (more or less stable, optimized) headers, plus the resource header file.
5. I repeated steps 3 and 4 a few times, always checking with IncludeManager for new candidates.
6. Steps 1 to 5 brought compilation time (release mode) down, from 90 to about 45 minutes.
7. I disabled generation of Browse Information for everything, since we do not seem to use it (and I could not find any information for what it is really good for...). This cut off another 6 minutes of the build process.
8. I added the /MP (multi processor support) switch to the C++ compiler command. Now the rebuild time was down to 22 minutes. This was all done on a single core PC.
9. I moved the whole solution to a dual core PC. Rebuilding the project takes 16 minutes there.
10. Creating a debug build is 5 minutes faster:
    • 17 minutes on the single core machine,
    • 11 minutes on the dual core machine.

更新2：

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

Above, where I mention "single core machine", actually a slower dual core machine is meant.