Improve breakpoint predictor caching for large projects #1149
Assignees
Milestone
Comments
This comment has been minimized.
This comment has been minimized.
|
It looks like that is just time in the breakpoint predictor. Just doing some quick local tests, essentially all the time is spent doing the file search. I think there is possibly some smarter caching that can be done if we avoid ripgrep, for example by knowing file mtimes, remembering the last sourcemap we saw if the mtime matches (which we do today, but only after discovering the sourcemap string), and not bothering reading the file if it doesn't match. |
connor4312
changed the title
99 tasks
|
Is this maybe a dupe of microsoft/vscode#153470? |
|
This was mostly covered by the PR I sent to fix that issue, but there are still a few more things I want to take care of |
98 tasks
This was referenced Dec 15, 2022
connor4312
added a commit
that referenced
this issue
Dec 18, 2022
For #1149 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 it doesn't need to read files at all if the mtime doesn't change. There remains some lower-level optimization: I'm going to improve how the cache results get stored (currently the cache file for VS code is 10's of MB of JSON.) Later, I'm going to improve how the source map URL is actually read from the file. Today we read the entire file into a string, but we can improve this significantly, since, by spec, the sourceMapURL is always at the end. That was the original reason I broke from the ripgrep-based approach, since ripgrep greps the whole file. 
connor4312
added a commit
that referenced
this issue
Dec 29, 2022
For #1149 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 it doesn't need to read files at all if the mtime doesn't change. There remains some lower-level optimization: I'm going to improve how the cache results get stored (currently the cache file for VS code is 10's of MB of JSON.) Later, I'm going to improve how the source map URL is actually read from the file. Today we read the entire file into a string, but we can improve this significantly, since, by spec, the sourceMapURL is always at the end. That was the original reason I broke from the ripgrep-based approach, since ripgrep greps the whole file. 
connor4312
added a commit
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
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
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
I sometimes see breakpoints being very slow to be set when debugging vscode. Here's a log where it took several seconds for the breakpoint to become solid red. This is using the normal "VS Code" launch config and code-oss was not very busy at the moment I set the breakpoint in searchView.ts.
vscode-debugadapter-bd6f7e46.json.gz
The text was updated successfully, but these errors were encountered: