Why does Conditional breakpoint decrease the application execution speed at debug time?

Question

When I use conditional breakpoint in VS2005 instead of using temporary code to check specific conditions, I noticed it takes more time and the execution speed is decreased!! Do you know why? and how to resolve this issue?

Exmaple:

    int sequence = atoi(m_SequenceNumber.GetAscii());
    if( sequence == 392914)//temporary code to check to step into code
    {
     int x = 0;//I put breakpoint here
    }

The previous code will execute faster than if I used conditional breakpoint with ( sequence == 392914)

Answer 1

I assume it is because it takes time to execute the condition. It is still a lot faster than manually stepping the necessary number of times tough.

Answer 2

Added temporary code can be optimized (at least a bit) by the compiler. Conditional breakpoint probably jumps to some visual studio code that will manually retrieve needed information to know whether it actually has to pause or not.

That would somehow explain why it takes more time. But i am just guessing.

Answer 3

It is better (if possible) to use a memory watchpoint than a conditional breakpoint. A conditional breakpoint (as others have pointed out) has to run additional code each time the execution pointer goes past that point in order to determine if it would break or not - obviously this takes additional time. A memory watchpoint of a certain type gets to use certain special hardware registers - there is a limit on how many watchpoints you can set that can get accelerated, but if you can use them there is almost no speed penalty.

A memory watchpoint is set using the breakpoint window. You do not set it on a line of code, but rather on an address in memory. This suggests the obvious limitation, it only works for things you can actually take the address of, such as global variables and dynamically allocated areas of memory (using new etc). You are limited in how much memory you are allowed to watch (based on the CPU, I think you probably get more or less special registers allocated).

I'm not actually sitting in front of VS right now, but roughly speaking, you right click in the breakpoints window and choose something like "new data breakpoint". You then enter the address of the memory and the size in bytes. Whenever the value changes your watchpoint will fire. This is particularly useful for figuring out memory corruption issues.

Answer 4

I have run into this problem in the past as well and never really found a way to continue using Conditional Breakpoints within a large loop without affecting performance. I did learn that you could insert some temporary code like this that would not affect performance and would cause VS to break (same behavior as a Conditional Breakpoint).

if ( condition ) Debugger.Break();

Answer 5

Think about how you would implement a conditional breakpoint if you were writing a debugger. The only time the debugger has an opportunity to evaluate the condition is when the breakpoint is hit. So even though the breakpoint is conditional as far as you're concerned, as far as the processor is concerned the breakpoint is being hit everytime the instruction is executed. The debugger gets control and does the following:

• determines that the breakpoint is conditional
• evaluates the expression
• if the expression is false, the debugger continues execution
• otherwise, the debugger turns control over to you

So even if you never see the breakpoint hit (because the condition is not met), the debugger may be fielding the breakpoint and evaluating the condition thousands of times a second (or more maybe).