Repository navigation
Allowing to step over before loading a call stack and variables #25605
Description
Old issue was closed so I'm opening a new one.
#22807
Loading call stack and fetching local variables can be a long operations especially when there are a lot of threads started and call stacks are pretty long. Some debuggers (gdb for a example) allows you to do a step over before loading call stack or fetching local variables. Please allow debugger plugin to configure if it's ok to allow to step over before loading call stack and fetching variables.
Activity
isidorn commentedon Apr 28, 2017
Well call stack has to be known in order for the step to be "done", since the call stack deteremines the step location.
While the variables are fetched asynchrounisly. Namely, you should be able to step while the slow variables request is being completed (shown in the variables tree as a loading spinning icon)
wcscmp commentedon Apr 28, 2017
In order to know current location only the current frame is required. There is no need to know the whole call stack and most definitely there is no need to know call stacks of all the threads.
isidorn commentedon Apr 28, 2017
wcscmp agree.
fyi Andre Weinand (@weinand)
isidorn commentedon Apr 28, 2017
After discussing with Andre Weinand (@weinand) there is already a mechanism in the debug adapter protocol that the vscode only requests for 1 stack frame, after that is received it can request all the other stack frames.
An alternative approach would be that the stopped event has the top stack frame in the event, so vscode only requests the rest
Assigning to May to investigate
weinand commentedon May 11, 2017
Dirk Bäumer (@dbaeumer) we plan to improve stepping performance in this milestone.
debug: fetch first call stack to improve perf
debug: fetch the rest of the callstack lazily
isidorn commentedon May 12, 2017
wcscmp thanks for this great suggestion.
Now on each stop event we are only fetching the top stack frame, once that is done in the background with a delay we continue fetching the rest of the stack frames and the variables. If a new stop event occurrend we simply cancel the previous schedule of stackFrames fetching and variables - which in practice results that if a user quickly steps over his code we will only fetch variables and rest of the stack frame once he is idle.
Del Myers (@delmyers) Gregg Miskelly (@gregg-miskelly) Jimmy Thomson (@MSLaguana) Danny Tuppeny (@DanTup) Devon Carew (@devoncarew) Jan Jurzitza (@WebFreak001) roblourens Andy Sterland (@andysterland) Holger Benl (@hbenl) lukaszunity Sami Vaarala (@svaarala) Ramya Rao (@ramya-rao-a) vadimcn Felix Becker (@felixfbecker) David Wilson (@daviwil) Keith Hill (@rkeithhill) Don Jayamanne (@DonJayamanne) Jimmy Thomson (@MSLaguana) Peng Lyu (@rebornix) In order to benefit from this performance improvement debug adapters needs to support the
startFrameandlevelsarguments in theStackTraceRequest.Here's a performance comparision before and after the improvment:
debug: reduce callstack flashing by showing a stale remainder of the …
debug: refresh the variables tree lazily
debug: fetch the rest of the callstack lazily