How to work around Visual Studio Compiler crashes

Question

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).

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"

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).

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 complete build takes around 90 minutes.

---

Update:

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. 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.

Update 2:

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

Answer 1

If 1300 files are taking THAT long to compile then you are including waaaay too many header files that are unncecessary. I'd guess people have cut and pasted a bunch of headre files into a CPP file without thinking which headers they actually need so that loads of them are getting included when they ought not to be. I'm also guessing that you aren't forward declaring classes where you should be.

I'd suggest you need to spend some time going through your project and removing unnecessary #includes. I suspect this will fix your out of memory problems AND will improve your compile time.