[tunnel] JS Debug Terminal is too slow #167911
Assignees
Labels
bug
Issue identified by VS Code Team member as probable bug
debug
Debug viewlet, configurations, breakpoints, adapter issues
papercut 🩸
A particularly annoying issue impacting someone on the team
verified
Verification succeeded
Milestone
Comments
jrieken
added
the
papercut 🩸
jrieken
changed the title
connor4312
added
bug
|
This isn't really related to the tunnel (js-debug is a workspace extension) but is a good opportunity to improve. Related: microsoft/vscode-js-debug#1149 |
connor4312
added
debug
connor4312
added a commit
that referenced
this issue
Dec 16, 2022
connor4312
added a commit
that referenced
this issue
Dec 16, 2022
connor4312
added a commit
to microsoft/vscode-js-debug
that referenced
this issue
Dec 30, 2022
Fixes #1149 Fixes microsoft/vscode#167911 This does some overall system optimization for how the breakpoint predictor works. It achieves performance comparable to the VS Code API ripgrep globbing, with plain JS. And by using plain JS, we can do more optimizations in a future PR. Previously, we had an `ISearchStrategy` type that globbed for all sourcemap URIs in a target folder, and emitted those. Then the breakpoint predictor had an mtime-based cache to decide whether it would parse the sourcemap or not. This moves the caching responsibility into `ISearchStrategy`, which then takes a two-phase approach to processing files, allowing it to cache the intermediate result the breakpoint predictor previously cached itself. This means that: - Files never need to be read if their mtime doesn't change - When starting a new child session, we optimize further and don't stat compiled files that didn't previously reference the sourcefile. (We still stat all directories to see if there are new files to pick up) Some performance numbers: - vscode#167911 time on my computer going from 33s -> 16s - typescript: time to run mocha tests The new search strategy can be disabled by setting `enableTurboSourcemaps: false` in your launch.json. 
connor4312
added a commit
to microsoft/vscode-js-debug
that referenced
this issue
Dec 30, 2022
Fixes #1149 Fixes microsoft/vscode#167911 This does some overall system optimization for how the breakpoint predictor works. It achieves performance comparable to the VS Code API ripgrep globbing, with plain JS. And by using plain JS, we can do more optimizations in a future PR. Previously, we had an `ISearchStrategy` type that globbed for all sourcemap URIs in a target folder, and emitted those. Then the breakpoint predictor had an mtime-based cache to decide whether it would parse the sourcemap or not. This moves the caching responsibility into `ISearchStrategy`, which then takes a two-phase approach to processing files, allowing it to cache the intermediate result the breakpoint predictor previously cached itself. This means that: - Files never need to be read if their mtime doesn't change - When starting a new child session, we optimize further and don't stat compiled files that didn't previously reference the sourcefile. (We still stat all directories to see if there are new files to pick up) Some performance numbers: - vscode#167911 time on my computer going from 33s -> 16s - typescript: time to run mocha tests 52s -> 22s (without outFiles configured) The new search strategy can be disabled by setting `enableTurboSourcemaps: false` in your launch.json. 
connor4312
added a commit
to microsoft/vscode-js-debug
that referenced
this issue
Dec 30, 2022
Fixes #1149 Fixes microsoft/vscode#167911 This does some overall system optimization for how the breakpoint predictor works. It achieves performance comparable to the VS Code API ripgrep globbing, with plain JS. And by using plain JS, we can do more optimizations in a future PR. Previously, we had an `ISearchStrategy` type that globbed for all sourcemap URIs in a target folder, and emitted those. Then the breakpoint predictor had an mtime-based cache to decide whether it would parse the sourcemap or not. This moves the caching responsibility into `ISearchStrategy`, which then takes a two-phase approach to processing files, allowing it to cache the intermediate result the breakpoint predictor previously cached itself. This means that: - Files never need to be read if their mtime doesn't change - When starting a new child session, we optimize further and don't stat compiled files that didn't previously reference the sourcefile. (We still stat all directories to see if there are new files to pick up) Some performance numbers: - vscode#167911 time on my computer going from 33s -> 16s - typescript: time to run mocha tests 52s -> 22s (without outFiles configured) The new search strategy can be disabled by setting `enableTurboSourcemaps: false` in your launch.json. 
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
yarn run gulp vscode-darwin-arm64The debug terminal is such a great too, esp for all the engineering work I am lately doing, but being a debugger-driven developer that's too much to endure.
The text was updated successfully, but these errors were encountered: