Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: Visual-Studio optimization , +
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".
 
        /// <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:
        /// <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 8:23am
Edited 30-Nov-12 8:24am
v2

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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… Smile | :)
 
Good luck,
—SA
  Permalink  
v4

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

  Print Answers RSS
0 OriginalGriff 520
1 Maciej Los 290
2 Richard MacCutchan 265
3 BillWoodruff 265
4 Suraj Sahoo | Coding Passion 155
0 OriginalGriff 8,764
1 Sergey Alexandrovich Kryukov 7,437
2 DamithSL 5,639
3 Maciej Los 5,279
4 Manas Bhardwaj 4,986


Advertise | Privacy | Mobile
Web03 | 2.8.1411028.1 | Last Updated 30 Nov 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100