Vscode-cpptools: Debugging in VSCode is significantly slower than using command line

[nickaleks]

Type: Debugger

Describe the bug

• OS and Version: Ubuntu 18.04
• VS Code Version:

Version: 1.39.2
Commit: 6ab598523be7a800d7f3eb4d92d7ab9a66069390
Date: 2019-10-15T15:33:40.634Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 5.0.0-32-generic snap

• C/C++ Extension Version: 0.26.1
• Other Extensions: CMake (syntax highlighting, Clang-Format. Disabling them does not work.

When starting a debugger in VSCode, any action (step over, hitting a breakpoint) takes unreasonable amount of time. Sometimes it causes OS to suggest force quit for a window. I've used to GDB from the command line to see where the issue lies, and it is almost instant for actions such as hitting breakpoint.

There are about 10 threads running for the application, and their stacktraces are collapsed except for the main thread.

To Reproduce

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch",
      "type": "cppdbg",
      "request": "launch",
      "program": "path/to/executable",
      "args": [],
      "stopAtEntry": false,
      "cwd": "build/dir",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "miDebuggerPath": "path to debug script",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ]
    }
  ]
}

Additional context
I use custom script to launch debugging, as we use conan environment for dependencies (using source command), however it is done for the command line as well.

[pieandcakes]

The reason it is not the same as command line gdb is because we need significantly more information than you would get when hitting a breakpoint when you stop.

We make requests for:

• stack frames per thread
• stack frame variables
• all variables + children to show up in the watch window

Each of these results in a command sent to gdb and a response. If you want to see what is sent and received, you can enable in your launch.json the following text:
"logging": { "engineLogging": true }

This will show all the commands sent to/from gdb in mi format in order to display all the data when the debugger stops.

[nickaleks]

Is it possible to somehow limit the number of information which is loaded? Let's say I'm interested in a single thread only, can the stacktraces of other threads be not loaded anyway? The same for the children of the variables. Instead of loading everything in advance, request variable information only when I expand particular object.

I don't know whether it's possible, or even that useful, just interested in the potential solution, as it would be great to have a faster debugger. Anyway thank you for the explanation and for the extension itself, so far I am very happy with it.

[pieandcakes]

We get the requests from VS Code for the information which is sent to us using the VS Code Debug Adapter protocol. The problem lies in that each request from VS Code, we need to make multiple requests to gdb to get the data in the correct format to return. If you look at the "traceResponse" logging instead, you can see what we get from VS Code and what we return.

In order to get less data, VS Code would need to request less data.