Why are conditional breakpoints so slow?

Question

0.00/5 (No votes)

See more:

, +

So I'm debugging some code an I notice some odd behaviour when type == "CSSRule". Ok I figure, I'll add a conditional breakpoint. Stop in this method when type == "CSSRule".

C#

        /// <summary>
        /// Gets the type.
        /// </summary>
        /// <param name="type">The type.</param>
        /// <returns>System.String.</returns>
        private static string GetType(string type)
        {
// conditional breakpoint added here
            if (type == null) return null;
            if (TypeTranslations.ContainsKey(type))
                return TypeTranslations[type];

            // For some reason many types are used with the Constructor suffix.
            return TranslateClassName(type.Replace("Constructor", string.Empty));
        }

I run the program and after 10 minutes I give up and stop the program. Without the breakpoint, the program parses and rewrites 250MB of source code in 16,329 files in about 10 seconds.

Yes, this code is executed a kajillion times.

Instead I just add the evaluator to the code and add a normal breakpoint:

C#

        /// <summary>
        /// Gets the type.
        /// </summary>
        /// <param name="type">The type.</param>
        /// <returns>System.String.</returns>
        private static string GetType(string type)
        {
            if(type == "CSSRule")
            {
// breakpoint added here                
            }
            if (type == null) return null;
            if (TypeTranslations.ContainsKey(type))
                return TypeTranslations[type];

            // For some reason many types are used with the Constructor suffix.
            return TranslateClassName(type.Replace("Constructor", string.Empty));
        }

It stop almost immediately at the correct iteration.

Posted 30-Nov-12 7:23am

Yvan Rodrigues

Updated 30-Nov-12 7:24am

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-11-30T08:33:00

By apparent reasons.

For an unconditional breakpoint, you can seed a hardware instruction(s) to call a debugger. In particular, on x86, x86-64 or IE-64 instruction set architectures, there is a hardware support of debugging, and the interrupt instruction can be used to set a breakpoint. Please see:
http://en.wikipedia.org/wiki/INT_%28x86_instruction%29[^],
http://en.wikipedia.org/wiki/X86_debug_register[^].

Many other processors also have hardware support for breakpoints:
http://en.wikipedia.org/wiki/Breakpoint#Hardware[^].

The main point here is: when a breakpoint is unconditional, you don't waste any CPU time for the breakpoint until the code flow comes to the breakpoint instruction; the debugger should be invoked at the first occurrence of the breakpoint in the code flow.

It cannot work this way if the breakpoint is conditional. You need to inject some code, which checks up the condition first, and, depending on the result of the check, either continues execution or calls the debugger. You might perceive this as a low-performance process if many checks without passing the control to the debugger take place before it happens.

But should you consider this as low performance? If depends on what you want to it compare with. It can be considerably slower compared to the runtime without the debugger, but your purpose is to debug, right? So, compare it with the case when you still have millions of passes through the breakpoint, but make it unconditional, so the execution will be paused every time… Still slow? Well, you cannot guarantee the ease of debugging in all cases… :-)

Good luck,

—SA