regression: Breakpoints are too slow

[liuxingbaoyu]

Describe the bug
A clear and concise description of what the bug is.

I'm not sure when this regression was introduced, maybe I had this problem a month ago, but I didn't confirm it.
In the current latest version v1.76.1, when I enable breakpoints, it takes >5 minutes.
And in v1.64.1, it works very well and only takes <10s.

To Reproduce
Sorry this is a big repository.

git clone https://github.com/babel/babel
make bootstrap
yarn jest generator (JavaScript Debug Terminal)

Log File
I'm not sure how to use "trace": true in JavaScript Debug Terminal.

VS Code Version
1.76.2 (user setup)

Additional context
Add any other context about the problem here.

[connor4312]

Thanks for the instructions, unfortunately I'm not able to repro this. Time to run that command without breakpoints was ~9.5s, while with tests it was around ~17s. While certainly slower, some degree of slowdown is expected, including in the runtime as a result of enabling async stracktraces.

To get trace logs from the debug terminal, you can add this setting to your user or workspace settings

  "debug.javascript.terminalOptions": {
    "trace": true
  }

[liuxingbaoyu]

Thank you for your quick reply!
The slowdown seems to depend on the location and number of breakpoints, now I can no longer reproduce the >5 minute situation since I've removed all breakpoints.
But I just successfully reproduced the 50s situation and got the trace log.
vscode-debugadapter-f7fcdf38.json.gz

[liuxingbaoyu]

There seems to be something like caching, and now it only takes <20s for me to rerun. 😕

[liuxingbaoyu]

I also found a log run via F5 on the hard drive, not sure if it helps.(Attempts made when opening this issue)
Judging by the timestamp it has elapsed for about a minute.
vscode-debugadapter-56d4deb8.json.gz

[connor4312]

We do cache pretty smartly now, and I'm not sure there's much more to squeeze out of it without sacrificing correctness. It does look like the main slowdown in the log you sent was the breakpoint predictor, which we use to look for sourcemaps in the workspace before running your code. This is necessary since Node.js, until recently (and not in all versions we still support) did not have a way for us to ask it to pause before running sourcemapped scripts.

Anyhow, the general recommendation is to configure the outFiles pattern in the launch.json--or in this case the debug.javascript.terminalOptions configuration--to a more specific glob pattern to avoid the number of places we need to search for sourcemaps. It defaults to ["**/*.js", "!**/node_modules/**"].

[liuxingbaoyu]

Thanks for the detailed explanation, it's very useful! I closed VSCode cleanly, then it took 120 seconds. Maybe the performance change I thought earlier came from caching.
I tried outFiles and it works fine now. Thanks again!