Re: More info on PR/9711 (quadratic slowdown for deep stack traces)

[Joel Brobecker <brobecker@adacore.com>]

> This almost, almost works.  I can see two problems:
> 
> * Can the results of those checks ever change?  For instance, does
> "set backtrace past-main off" flush the stack frame?  If not, it won't
> take effect right away after this change.

Yes - that's one of the issues I knew about. It wasn't making sense
to redo the checks in the case of finding the frame from its ID,
but I suppose it would make sense for "bt" to stop after we "set
"backtrace past-main off".

I suppose we could immediately flush the extra frames when the setting
changes to "off", but on the other hand, I think that the right thing
to do in frame_find_by_id is to call get_prev_frame_1 anyway. I will
test that next.

> Have frame_find_by_id keep a cache with the same lifetime as
> current_frame.  If it saves the last frame it returned, we can try
> that frame and the previous frame before going on to searching from
> the current frame.

That's a good idea. It seems relatively easy to do, since I can see
that the current_frame is always reset to NULL through
reinit_frame_cache, so it should be easy to have the same lifetime
as the frame chain. I will see if I can implement that too.

-- 
Joel