Why are iterators causing very slow debugging in VS2010 even with _HAS_ITERATOR_DEBUGGING, _SECURE_SCL, _SECURE_SCL_THROWS set to 0

Question

I've been trying to track down why it takes so long to debug our program when in debugging mode. After using xperf to see what the stacks looked like it was obvious that we were spending a huge amount of our time in the iterator and the STL containers. I googled this for awhile and found the options

_HAS_ITERATOR_DEBUGGING=0
_SECURE_SCL=0
_SECURE_SCL_THROWS=0

And I set all of those in code with a #define

#define _HAS_ITERATOR_DEBUGGING 0
#define _SECURE_SCL 0
#define _SECURE_SCL_THROWS 0

But that didn't seem to work, so then I tried it using the preprocessor definitions inside of the visual studio project, but that still didn't seem to help.

I've tried just about every permutation I can think of, including setting them in headers, and after all the includes, but no matter what I do, I'm not seeing a performance increase while debugging. To give an example, when running in release mode this series of operations takes about 140 seconds. In debug mode it takes a little over 2,400 seconds. Roughly 17-18 fold increase in processing time.

Some additional information, the process that hosts these C++ dll's is a C# .net 4 process, and I enabled unmanaged code debugging. Basically all the process does it load up the DLLs for us. All the real work is done in the c++ code.

I included the full compiler command line below.

/I"..\CommonInclude" /Zi /nologo /W4 /WX /Od /Oy- /D "_CRT_SECURE_NO_WARNINGS" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_USRDLL" /D "ENGINE_EXPORTS" /D "_HAS_ITERATOR_DEBUGGING=0" /D "_SECURE_SCL=0" /D "_SECURE_SCL_THROWS=0" /D "_VC80_UPGRADE=0x0710" /D "_WINDLL" /D "_MBCS" /Gm- /EHa /MDd /GS /fp:precise /Zc:wchar_t- /Zc:forScope /GR /Yu"StdAfx.h" /Fp".\Debug/Foo.pch" /Fa".\Debug/" /Fo".\Debug/" /Fd".\Debug/" /Gd /analyze- /errorReport:queue /EHa -Zm350 /MP3 

Any ideas why this would be as slow as it is?

Answer 1

Based on your description, this jumps out immediately:

I've been trying to track down why it takes so long to debug our program when in debugging mode. After using xperf to see what the stacks looked like it was obvious that we were spending a huge amount of our time in the iterator and the STL containers.

If you use the node-based containers (e.g., map, set, unordered_map, unordered_set, multimap, multiset, list, etc.), and run from the debugger, you may encounter issues that stem from those containers allocating a ton of objects with small sizes. When you run an application from the debugger in Windows, the OS switches the process heap to the debug heap. If you have many node based containers under load, freeing them will take up a lot of time with the debug heap.

A simple fix is to disable the debug heap by adding the following to the Environment section of the debugging options: _NO_DEBUG_HEAP=1

That disables the debug heap.

Answer 2

One thing that makes a huge difference is that by default functions are not inlined in debug mode. That adds a lot of time to code using many small accessor functions.

I have programs where the difference between debug and release mode is a factor 100+, without depending on iterators.

Answer 3

A couple of things to try:

• Use a profiler, eg the free AMD CodeAnalyst as it will give you callstacks and is generally a lot easier to use than Xperf. Even though you're dealing with debug code you may still find some hotspots
• Create a release build with optimisations switched off (you could create a separate configuration for this). This will turn off the iterator debugging (in case that is the cause of your slowdown), but may give a lot more useful debugging information than a raw release build. Check that the option to Omit Frame Pointers is enabled