Debug builds compile much more slowly than release

Question

Under Visual Studio 2005 we have a single library w/ 195 cpp files which takes about 2 minutes to build for release but about 6 minutes to build for debug.

I always thought release builds should take longer because of optimization. Why would a debug build take so much longer than release? Is there anyway to speed our debug build up to be as fast as release?

We do have a fair amount of boost/stl code.

Answer 1

Best guess: Debug-builds are I/O-limited, while Release-builds are processor-limited (in this case).

We've done extensive benchmarking on our build system -- lots of large projects, some small. The DEBUG builds write out lots of *.pdb information, much larger *.obj files (for the extra debugging information), etc. The result is massively-more disk activity. This is accentuated even further if you have lots of "literals" in your source code (tables, symbols, string-literals), etc.

In contrast, the RELEASE builds write out much smaller *.obj files, and doesn't bother writing the "debug" databases (if you compile RELEASE with typical switches). However, the linker in RELEASE builds has to do its optimizations and other significantly-more work that is just not done in DEBUG, so it's processor-bound. This is further time-penalized for RELEASE if you "compile-to-maximize-speed/size" with the most challenging-to-the-linker switches.

(However, yes, the RELEASE build must still I/O update-the-addresses in the executable-being-built-on-disk, but since the executable is so much smaller in the RELEASE build, you page much less, so the I/O penalty in RELEASE build is not as much as for DEBUG build.)

You're observing a 3x "RELEASE is more expensive than DEBUG". That's about right for some projects that are I/O-bound with lots of templates, many symbols and literals, etc. Check your drives -- are they getting full, or just "slow-drives", and/or with some bad sectors? Those will make it worse (slower) for the DEBUG builds.

Yes, other builds should be the other-way-around, with "RELEASE something like 3x more-expensive than DEBUG". Those builds are processor/linker-bound, rather than I/O-bound.

[UPDATE], I see in the comment-on-the-question that this is for "static-library, no-linking". That's pretty-much the worst-case-scenario for a time-penalty for I/O (lots of disk activity, no linking), and without a processor-penalty (since no optimizations are being done). So, if you have a 3x "DEBUG-is-slower-than-RELEASE", that's probably about as bad as it can get (for this project), and that's not atypical. When you add linking options, the RELEASE will get slower.