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.

Blighter

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

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.

Eyrie

yes, there are a lot of includes in the project, and I am trying to reduce those as well. Is there a tool which can help me identify the "critical" modules (those which include most others)? – Blighter

try Doxygen (stack.nl/~dimitri/doxygen). Quoting from its manual: # An include dependency graph is generated for each documented file that includes at least one other file. This feature is currently supported for HTML and RTF only. # An inverse include dependency graph is also generated showing for a (header) file, which other files include it. Just make sure that the Doxygen's configuration file (called Doxyfile) does not have HIDE_UNDOC_RELATIONS set so you get output for all classes/items. – Chrestomathy

Answer 2

I'd have to agree with Goz, take a look at this (SO) post to see ways to help remove redundant header files.

Our C++ solution is of this rough size and used to take us 50 mins to compile, by careful header file analysis, we got that down to 8 mins.

Itinerary

Thanks. I've also installed the ProFactor IncludeManager. Now how can I identify the most critical modules? Is there a suggested method? – Blighter

It has been a while since we did this in anger, but I think we started by looking at the the project include and project details structure and trying to see if there was anything obviously wrong (unexpectedly included), then we moved down to key files we knew were taking a long time to compile and looked at the Build Impact on those. I think that once we'd sorted out what should and should not be in stdafx.h that made the most difference. You may actually want to include more into the stdafx.h if it is included into lots of files and then takes a long time to compile. – Itinerary

Answer 3

IncrediBuild (distributed build system for VC++) besides the time-saving has an additional helpful function. It will restart a compile automatically if the remote machine fails to return results. So you should be able to get full builds, without crashes in 5 or perhaps 10 minutes.

Timeworn