Community
Participate
Working Groups
The disassembly view should not access the target when there is outstanding stepping requests, it should wait until no more outstanding stepping request before updating on the suspend event. I have observed 100% improvments using this approach with TI debugger, and noticible improvement with gdb debugger.
Does this mean the instruction pointer is not progressing while a step is pending?
(In reply to comment #1) > Does this mean the instruction pointer is not progressing while a step is > pending? Yes. Right now, the disassembly view is not synchronized with the instruction pointer while stepping, i.e handleTargetSuspended handler execute asyncExec, it is lagging behind each step for updating PC. Also retriving disassembly is done asynchronously on the DSF executor. Note that there is an option to synchronize views for every step, it is under Run/Debug | View Performance. The disassembly should support this option and synchronize view update and instruction pointer update for each step. I'll file a separate bug entry for this enhancement. Here is a simple fix for optimizing the DSF disassembly view implementation, this is based on Pawel's suggestion on the mailing list. Before calling fCallback.handleTargetSuspended in handeEvent(ISuspendedDMEvent) it needs to check if there is outstanding stepping request. Is this the right place to insert the code? I have experimented with this check and stepping is much faster when the Disassembly view is open. I am not sure if we need to do the same thing for the IResumedDMEvent handler, because I don't see any performance improvement with the change in the handler. The change is only couple lines of code, so I am wondering whether we can have this fix for Indigo release? Is it too late?
(In reply to comment #2) > The change is only couple lines of code, so I am wondering whether we can have > this fix for Indigo release? Is it too late? This is not just a fix, but a major change in behavior. I would be surprised when the view stops updating the IP. It may drop one or the other step (that's the issue you mention above), but I would still want it to update with every step. If you want it to behave different, we probably need a preference. BTW, the expensive thing is the retrieval of disassembly data, so an alternative approach would be to block just the retrieval of new data. In any case, Indigo is not a viable target for that kind of change.
(In reply to comment #3) > In any case, Indigo is not a viable target for that kind of change. Sure, we can wait for post Indigo for this change.
