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