On Jul 15, 2006, at 4:11 PM, Nick Roberts wrote:
> Jim Ingham writes:
>> We don't do what Nick's suggesting. We do do
something similar for
>> shared library notifications - we emit async
notifications for shared
>> library load events from gdb so Xcode doesn't have
to stop on solib
>> events & get the shlig list. Similarly if a
shared library load
>> causes a pended breakpoint to get loaded we tell
about that as well.
>>
>> But we don't do anything for stack changes. Note,
except in the case
>> where you have gotten stuck in some kind of
pathological recursion, I
>> would be surprised if it's consing up the stack
list for the MI that
>> takes a significant portion of the time, so I'm
not sure this example
>> isn't a false optimization. But anyway, we don't
do that.
>
> I thought previous discussion (Vladimir Prus) suggested
that
> -stack-list-argments, at least, was time consuming. If
the stack is
> 1000's of
> frames deep, it must surely be time comsuming to
compute and re-
> display it at
> every step. The depth can be restricted but I think
you have said
> that the
> first ones take are the hardest to compute.
We have a simple backtracer that just follows the frame
pointer, and
doesn't do any of the fancy unwinding of registers, etc.
When I get
it to print roughly the same information as the ordinary
-stack-list-
frames it's ~10 times faster than -stack-list-frames. So
I'm pretty
sure most of the time in -stack-list-frames is doing real
work
computing the backtrace, and only a small portion is consing
up the
output. To tell whether the stack has changed or not you
have to do
the backtrace (even if you don't report it.) So my guess
is this
change wouldn't save very much time.
The shared-libraries one was a win because we got the UI out
of the
process of stopping & starting again on shared library
hit. For
>
> In any case, we need to be scientific about it, so I
propose to add
> a time
> field to the MI output. ISTR that Apple's MI already
has this. Are
> you
> planning to include this (or the async notifications
for shared
> librarys) in
> the DMI specification? I would like to avoid
unnecessary
> duplication of
> effort.
Dunno if the timing belongs in the spec, since it's more of
a
diagnostic thing. But it is really handy to have... The
shared
library notification is really useful and probably should go
in.
Jim
_______________________________________________
dmi-discuss mailing list
dmi-discuss lists.freestandards.org
http://lists.freestandards.org/mailman/listinfo/dmi-d
iscuss
|