Re: why are conditional breakpoints SO SLOW?
Re: why are conditional breakpoints SO SLOW?
- Subject: Re: why are conditional breakpoints SO SLOW?
- From: Jens Alfke <email@hidden>
- Date: Tue, 18 Mar 2014 09:27:41 -0700
On Mar 18, 2014, at 8:43 AM, Dallman, John < email@hidden> wrote: Sadly, that is quite easy. The way conditional breakpoints work is that the breakpoint
instruction is put into the code, and the app starts.
And in general a breakpoint instruction generates a type of CPU trap/exception — the same category as a segfault or divide-by-zero. These are very expensive at the CPU-cycles level, requiring a context switch and saving CPU state to RAM. At that point the debugger has to read the CPU state, figure out what breakpoint the CPU corresponds to, and so forth. Finally on the way back to your code, there’s another context switch.
If you want to make this faster, put the conditional test into your code and set a regular breakpoint on a line that only gets hit if the condition matches. (Is there a function that will do the equivalent of hitting a breakpoint, i.e. a modern-day equivalent of the old Debugger() call?)
—Jens |
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden