Why is running attached to the debugger so slow?

Question

What is going on that causes a debug build to be so much slower attached to the debugger compared to unattached? They are both the same exe running.

Edit: Most of th

Answer 1

There are a couple of reasons why running with the debugger attached can be significantly slower than unattached. The most likely causes are

• Excessive number of break points
• Breakpoints which have expensive conditionals
• Too many trace points

The first thing to try is disabling all break points and seeing how that effects perf

Answer 2

If it isn't OutputDebugString or piles and piles of breakpoints slowing everything down, try these:

• Windows debug heap - your process gets the debug heap if it is running under a debugger, no questions asked. To disable this when running under the Visual Studio debugger, visit the debugging page of the project properties and add _NO_DEBUG_HEAP=1 to the environment.

  (The Windows debug heap is a separate thing from the CRT debug heap. Your release build will get the Windows debug heap too, if it runs under a debugger.)

• The program loads lots of DLLs that have symbols. When a DLL is loaded, Visual Studio tries to find symbols for it. If there are symbols available, this can take time. There's not much you can do about this except to rearrange your program so that it loads DLLs less often.

• Check for any calls to IsDebuggerPresent - this can introduce arbitrary differences between running in the debugger and outside it.

(As a final throwaway suggestion - I would also be suspicious that exceptions (whether C++ or structured) might be a bit more involved when the process is being debugged. So if your programs throws a lot, maybe that could be a bit slower when it's being debugged.)

Answer 3

If your debugger uses software watchpoints it internally step executes the code and checks these points and changes in variable values.

The [VS] debugger can only support 4 hardware data breakpoints. If you use expressions (a + b), debugger uses emulation mode.

Also, loading debugging information for libraries is slower and it contributes to the perceived execution time (response time).

Reference

Answer 4

Do you have a lot of logging via OutputDebugString? Output produced by OutputDebugString is received by a debugger, but ignored when not running under a debugger.