Visual Studio - Runtime impact of conditional and disabled breakpoints

Question

After spending a little time wondering why my app was running a particular scenario very slowly with the debugger attached, I discovered that this was due to having a conditional breakpoint (whose condition was never being met). This seems reasonable, as the CPU would signal the breakpoint and VS would need to evaluate the condition before allowing execution to continue. These transitions must be costly.

I assume that a breakpoint in a code path that is not executed has no runtime impact.

So my question is twofold:

1. Are there any resources that can quantify the cost associated with conditional breakpoints, and if so is there anything one can do to reduce their runtime evaluation cost?
2. Is there any cost associated with a 'disabled' breakpoint? By disabled I mean that VS displays the breakpoint marker in the gutter with a hollow circle.

Of course if anything I've mentioned above doesn't make sense, then please point me in the right direction.

Answer 1

It's hard to quantify the cost of a conditional breakpoint. The expression in a conditional breakpoint is evaluated using the exact same semantics as if you had typed it into the watch or immediate window. Expressions of this nature are not actually executed in the client program but instead handled by the language specific expression evaluator. It's not really possible to profile these types of evaluations in a meaningful way.

However I can list a few things that are known to be slower in a debug window eval

• Function Calls: They are the slowest thing you can do because the function call requires the debuggee process to be restarted so that the func eval can occur in the process
• String comparison: Under the hood these go back to func evals

As for disabled breakpoints, no they do not affect the running of the application.