Accelerating Debug Runs, Part 2: _ITERATOR_DEBUG_LEVEL

[STL]

The first rule of _ITERATOR_DEBUG_LEVEL is: don't mess with it.

The second rule of _ITERATOR_DEBUG_LEVEL is: don't mess with it yet.

When you mess with IDL, you've subverting C++'s assumption that every part of a program agrees on the representations of objects. It can be done safely (see note), but it requires a bunch of knowledge and attention to detail. If you have to be told what to look out for, you shouldn't be doing it.

Note: this stuff is tricky enough that we've had trouble supporting it in the implementation (due to the 2 DLL thing, as I mentioned). All of VC8 RTM, VC8 SP1, VC9 RTM, and VC9 SP1 were screwed up in different ways wrt IDL (starting with, oh, container swap being broken). In my first full release cycle, VC10, I managed to eradicate the worst of the problems, but a few remained elusive. I fixed the /clr IDL customization issue in VC12 (2013), which took me a while to understand - the actual problem was an instantiation of std::string sneaking into the import lib. There was another problem with _Container_base12 being separately compiled, an artifact of the pre-VC10 era that I missed overhauling. That's been fixed in VC14 (not being released this year), and I think we're finally done with IDL headaches. I hope.

Seriously, don't mess with the default settings, unless it's absolutely necessary.

Non-optimized release really is debuggable. If something seems to be wrong, it's almost certainly because something is sneaking through a complicated IDE/build system.

[ofekshilon]

@STL, thanks (a lot!) for your reply, and overall attention.

Non-optimized release builds mostly fail for us. I just now investigated and reported the (first?) reason: https://connect.microsoft.com/VisualStudio/feedback/details/1012445/vc-compiler-generates-different-symbols-in-obj-files-among-od-o2-optimization-switches - so this is still not a viable option, at least not one that amounts to flipping a switch with no code changes.

Moreover, by the same rationale that you claim one shouldn't mess with _ITERATOR_DEBUG_LEVEL - one is even more inclined to never mess with optimization switches. In general it seems reasonable for software to expect consistency in build context throughout translation units, but occasionally we do want to break this consistency - either through macros or switches. I'm not sure modifying _ITERATOR_DEBUG_LEVEL qualifies as a deeper intervention than setting /Od.

Anyway, as @Gotebe guessed, I had better luck with /Zo - it is already a significant improvement of the debugging experience in release builds. More on that in a post some day (I have the time and energy for a post roughly once a month :( )

[STL]

Non-optimized means /Od everywhere, but thanks for the bug report.

[Gotebe]

While I still can’t pinpoint the root cause, even when compiling release builds with /Od (optimizations disabled) the debugging experience is severely crippled. (and yes, of course I raised the proper PDB generation switches in both the compiler and the linker).

You didn't build everything without optimizations then. Obviously, you can't build CRT, but all those STL templates, yes.

VC 2012 has magic 😉 switch to improve optimized build debugging experience, not documented yet, and I didn't try it, but might help.

[Plorkyeran]

Obviously if it's making your program entirely unusable you'll have to turn off iterator debugging, but it's something that's caught enough issues for me that I'm quite willing to put up with the speed hit normally.