|
I just found that there seems to be a bug in the cache
flushing logic:
Bug 310992
- [vm][cache] Unnecessary cache flushing of thread
children on suspended event
By fixing this, the stack depth retrieval can be
avoided (until the full stack refresh
happens).
Toni
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
|
