Open letmaik opened 6 years ago
@letmaik That would be up to VS Code to query less information from us. The locals are queried by VS Code to show in the locals window so if it didn't query it, we wouldn't make the query. You can see the VSCode protocol information by enabling "traceResponse": true
in the logging block and you can see what VS Code is asking for. I don't think we have any control from the debugger standpoint.
I found that there's a supportsVariablePaging
capability in the debug adapter protocol. This sounds suspiciously like it would help in this case, assuming that VS Code makes use of that functionality. Is that supported by this extension currently? Where do I find the source code of the debug adapter that this extension uses?
@letmaik We currently don't support it. The code for the debugAdapter is located in https://github.com/Microsoft/MIEngine.
Type: Debugger
Describe the bug
The debugging experience with gdb becomes unusable when there is a large number of local variables, e.g. 100-200, half of them arrays. With
"engineLogging": true
and gdb pretty-printing disabled, I can see in the debug console that when a breakpoint is hit or when I forward one step the C++ extension is querying gdb sequentially for information about each local variable, each request taking around half a second. This means that each step to the next line takes around half a minute in my case for this code base.When stepping through code it is often not needed to know information about all variables, but instead just the ones that are in the watch window. If only those were fetched and the rest lazily in the background or on demand, then stepping would be fast even with large numbers of local variables. Maybe there is another way to improve performance, but this is what came to my mind from an outside perspective.