views:

60

answers:

2

The attached, trivial, test program tests the performance of emptying a simple std::map. Using MSVC 2008 and 2010, the debug build will take <30seconds when executed from a command prompt but almost 3 minutes when executed from within the debugger. The call to clear() is entirely responsible for the difference. If I break into the debugger the callstack will always point to HeapFree.
Question: Why the huge difference? Can I somehow change debug heap settings so it'll be fast when executed in the debugger?

#include <map>

int
main ( int, char )
{
    std::map< time_t, double > test;
    for ( int i = 0; i < 1000000; ++i )
    {
        test[i] = i / 3.14;
    }
    test.clear();
    return 0;
}
+2  A: 

The debugger adds a lot of iterator checking for safety. You can disable the iterator checks with the _HAS_ITERATOR_DEBUGGING=0 flag but I don't suggest it. See this blog entry for more information.

edit:

In the response to below, it could if there's debug hooks into the application gathering information to assess the stack or some other process within the debugger monitoring your code. I'm speculating here because I don't know what add-ons you've got installed. However, from the command line you could be using the non-debug executable. I've made that mistake myself and it's easy to do.

wheaties
Thanks for the answer but the change didn't make a discernable difference. It also wouldn't explain the difference between execution in the debugger vs the command line - or would it?
BuschnicK
+2  A: 

Another suggestion, if wheaties' answer doesn't work: trying setting the environment variable NO_DEBUG_HEAP=1 in the program's initial environment. This disables Windows' internal debug heap, which might make it harder to debug memory corruption problems.

This KB article mentions the flag, and you can infer that the default (low-fragmentation heap) is disabled if the program is run in a debugger without that environment variable.

Edit: the environment variable might be called _NO_DEBUG_HEAP (with an initial underscore), but I'm not sure. This blog post uses _NO_DEBUG_HEAP, and discusses how the debug heap can slow down their program by 3-5 times.

Doug
Yes! That's it, thank you. Adding "_NO_DEBUG_HEAP=1" (with leading underscore) to the environment variables fixes the problem. I'll re-enable it periodically for testing, but a factor 100 speed difference for regular debugging is just too much.
BuschnicK