Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: add turbo mode for the breakpoint predictor #1498

Merged
merged 2 commits into from
Dec 30, 2022

Conversation

connor4312
Copy link
Member

@connor4312 connor4312 commented Dec 30, 2022

AKA how to be faster than ripgrep ;)

Fixes #1149
Fixes microsoft/vscode#167911

This does some overall system optimization for how the breakpoint
predictor works. It achieves performance exceeding the VS Code API
ripgrep globbing, with plain JS.

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 (6 second baseline without a debugger)
  • typescript: time to run mocha tests 52s -> 22s (without outFiles configured, 12 second baseline without a debugger)

The new search strategy can be disabled by setting
enableTurboSourcemaps: false in your launch.json.

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.

![](https://media4.giphy.com/media/cRH5deQTgTMR2/giphy.gif?cid=ecf05e47r7gdpd1vzjtyo72z0ymmob3ltfjz7ts4cs64n18i&rid=giphy.gif&ct=g)
@connor4312 connor4312 marked this pull request as draft December 30, 2022 00:51
@connor4312 connor4312 marked this pull request as ready for review December 30, 2022 00:54
@VSCodeTriageBot VSCodeTriageBot added this to the January 2023 milestone Dec 30, 2022
@connor4312 connor4312 enabled auto-merge (squash) December 30, 2022 00:59
@connor4312 connor4312 merged commit ac31998 into main Dec 30, 2022
@connor4312 connor4312 deleted the turbo-sourcemaps branch December 30, 2022 09:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[tunnel] JS Debug Terminal is too slow Improve breakpoint predictor caching for large projects
3 participants