Hi,
IStack.getTopFrame() and the delayed refresh logic in StackFramesVMNode
is primarily intended at optimizing stepping speed. When stepping, the
full refresh of the stack frames is delayed by 200ms and if in that
time a new step is executed, then the refresh is canceled. However,
this mechanism relies on the stack service for caching some stack
information while the target is stepping stepping so it's not ideal.
Specifically, as you pointed out the stack depth is retrieved from the
service to calculate the select delta for the top stack frame. I think
we could avoid this call if we were to enhance the view model cache a
little bit. I recently filed a bug for this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=310518.
Cheers,
Pawel
On 04/28/2010 06:10 AM, ken.ryall@xxxxxxxxx wrote:
Pawel,
I’m working on optimizing bits of the EDC debugger and have run across
an issue with displaying stack frames. In some circumstances when we’re
building the list of stack frames determining the next frame can become
an lengthy operation. This would be seem to be what IStack.getTopFrame
is designed to do, just return the first one to give the user immediate
feedback when a context is suspended, then bring in the remainder of
the frames later. But IStack.getStackDepth is also called, which I
understand is supposed to always return the complete number of frames,
which will bring on some of the lengthy work I’m trying to defer.
So I must be misunderstanding how this works, I’m looking into it but I
thought I would see if you had any advice.
Thanks - Ken
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
