Visual C++: Difference between Start with/without debugging in Release mode

What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?

I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!

(Assume that the Release and Debug modes are the typical con开发者_开发百科figurations you get when you create a new Visual C++ project.)

The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.

You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1

This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived: http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx

"Start without debugging" just tells Windows to launch the app as it would normally run.

"Start with debugging" starts the VS debugger and has it run the app within the debugger.

This really doesn't have much to do with the debug/release build settings.

When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:

• The emitted code won't be optimised, so is easier to debug because it more closely matches your source
• The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
• Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.

Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.

When you run 'with debugging' things perform differently for several reasons:

• The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
• Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
• A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.

IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.

IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.

When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.