Vscode: Allowing to step over before loading a call stack and variables
Old issue was closed so I'm opening a new one.
https://github.com/Microsoft/vscode/issues/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.
wcscmp
All 6 comments
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)
isidorn
on 28 Apr 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.
wcscmp
on 28 Apr 2017
@wcscmp agree.
fyi @weinand
isidorn
on 28 Apr 2017
After discussing with @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
isidorn
on 28 Apr 2017
@dbaeumer we plan to improve stepping performance in this milestone.
weinand
on 11 May 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.
@delmyers @gregg-miskelly @MSLaguana @DanTup @devoncarew @WebFreak001 @roblourens @andysterland @hbenl @lukaszunity @svaarala @ramya-rao-a @vadimcn @felixfbecker @daviwil @rkeithhill @DonJayamanne @MSLaguana @rebornix In order to benefit from this performance improvement debug adapters needs to support the startFrame and levels arguments in the StackTraceRequest.
Here's a performance comparision before and after the improvment:
isidorn
on 12 May 2017
Related issues
shanalikhan
路
3Comments
biij5698
路
3Comments
v-pavanp
路
3Comments
DovydasNavickas
路
3Comments
VitorLuizC
路
3Comments
Most helpful comment
@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.
@delmyers @gregg-miskelly @MSLaguana @DanTup @devoncarew @WebFreak001 @roblourens @andysterland @hbenl @lukaszunity @svaarala @ramya-rao-a @vadimcn @felixfbecker @daviwil @rkeithhill @DonJayamanne @MSLaguana @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: