Re: [patch][python] 1 of 5 - Frame filter Python C code changes.

[Phil Muldoon <pmuldoon at redhat dot com>]

On 21/03/13 20:55, Tom Tromey wrote:
> 
> On irc you mentioned that performance wasn't great.
> I'm wondering if you are working on the frame stash fix.
> I think it would be good for that to go in first, so that there isn't a
> window where frame filter performance is bad.

Frame printing is about 20% slower, and that is really only noticeable
on backtraces of 10,000 frames or more.  Frame filtering and
application of decorators is instant.  So performance is comparable in
all but the most demanding of situations.

I think a frame stash using a hash table is doable, but I think it is
overkill because I am extremely suspicious of the frame to frame
object code.  As we get the older() and newer() frames we invalidate
the frame stash.  The reason for getting the two nearest older and
newer frames is dubious in the extreme.  A frame will always have a
frame level - that is GDB assigned.  Even completely busted inferior
frames, will be properly encapsulated in a GDB frame, and, have a
level assigned.

The only other scenario I can think of for the logic is if GDB itself
has encountered corruption in the call stack and this is to preserve
the last place.  But at that point why are we hiding that from the
user?  Things are likely going to fail, and fail badly, soon.  My
proposal is just to use the existing find_frame_by_id function and not
bother with this other stuff.  That will stop invalidating the frame
stash and likely solve the performance issue.

Cheers,

Phil