Why does the application work with the debugger so slowly?

Question

What happens because the debug build is so slower connected to the debugger compared to the untethered one? They both work on the same computer.

Edit: Most answers focus on breakpoints. I am still running like dirt without breakpoints, an OutputDebugString or anything in the clock window. What about CRT debugging, Runtime stack checks, and debug heaps?

Answer 1

If it's not an OutputDebugString , or if piles and heaps of breakpoints slow things down, try the following:

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

  (The Windows debugging heap is a separate thing from the CRT debugging heap. In your assembly, you will also get Windows debugging if it runs under the debugger.)

• The program loads many DLLs that have characters. When the DLL loads, Visual Studio tries to find characters for it. If there are symbols, this may take some time. There is not much that can be done there, except to change the order of your program so that it loads DLL files less often.

• Check for any calls to IsDebuggerPresent - this can lead to arbitrary differences between running in and out of the debugger.

(As a final sentence with sentences - I would also be suspicious that exceptions (whether C ++ or structured) may be a bit more active when the process is debugging. Therefore, if your programs throw a lot, it might be a little slower when debugging.)

Answer 2

If your debugger uses software breakpoints, it executes the internal code of the code and checks these points and changes in the values ​​of variables.

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

In addition, loading debugging information for libraries is slower and contributes to the perception of runtime (response time).

Link

Answer 3

Do you have a lot of registration through OutputDebugString? The result obtained by OutputDebugString is accepted by the debugger, but is ignored when it does not work under the debugger.

Answer 4

There are several reasons why working with an attached debugger can be significantly slower than an unattached debugger. The most likely causes are

• Excessive Breakpoints
• Breakpoints with expensive conventions
• Too many trace points

The first thing to try is to disable all breakpoints and see how it affects perf