-
Notifications
You must be signed in to change notification settings - Fork 311
Debug console very slow when debugging new module-ified/bundled TypeScript compiler #1433
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
Labels
bug
Issue identified by VS Code Team member as probable bug
Comments
5 tasks
connor4312
added a commit
that referenced
this issue
Dec 8, 2022
Fixes #1433 There were a couple problems: - TS uses a `customDescriptionGenerator`. Previously this was being invoked on each individual property. I've merged this with the logic we added for custom `toString()` representations, so that we run it only once for an object and return a map of its properties. - TS has thousands of variables in each scope. We call `Runtime.getProperties` to get scope variables to use in completions. It seems like getProperties, which does not have any 'limit' parameter, is blocking. We still need this to do sensible completions, but now each stacktrace caches its completions instead of getting new ones on every request. With these changes, there may still be a little REPL stall on the first evaluation (until the first completions call finishes, which takes 3-5s on my macbook), but after that it should be appropriately snappy.
connor4312
added a commit
that referenced
this issue
Dec 8, 2022
Fixes #1433 There were a couple problems: - TS uses a `customDescriptionGenerator`. Previously this was being invoked on each individual property. I've merged this with the logic we added for custom `toString()` representations, so that we run it only once for an object and return a map of its properties. - TS has thousands of variables in each scope. We call `Runtime.getProperties` to get scope variables to use in completions. It seems like getProperties, which does not have any 'limit' parameter, is blocking. We still need this to do sensible completions, but now each stacktrace caches its completions instead of getting new ones on every request. With these changes, there may still be a little REPL stall on the first evaluation (until the first completions call finishes, which takes 3-5s on my macbook), but after that it should be appropriately snappy.
connor4312
added a commit
that referenced
this issue
Dec 9, 2022
* fix: improve repl/variable/completion performance for TS Fixes #1433 There were a couple problems: - TS uses a `customDescriptionGenerator`. Previously this was being invoked on each individual property. I've merged this with the logic we added for custom `toString()` representations, so that we run it only once for an object and return a map of its properties. - TS has thousands of variables in each scope. We call `Runtime.getProperties` to get scope variables to use in completions. It seems like getProperties, which does not have any 'limit' parameter, is blocking. We still need this to do sensible completions, but now each stacktrace caches its completions instead of getting new ones on every request. With these changes, there may still be a little REPL stall on the first evaluation (until the first completions call finishes, which takes 3-5s on my macbook), but after that it should be appropriately snappy. * fixup! update test fixtures * address pr comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
In TypeScript 5.0, we're changing our codebase to be implemented as modules, which are then bundled. When debugging our codebase, the debug console is very, very slow; completions, evaluation, etc, take many many seconds.
To Reproduce
Steps to reproduce the behavior:
launch.template.json
tolaunch.json
in.vscode
createTypeChecker
inchecker.ts
2dArrays.ts
ts
variable. On my machine, this took ~4 seconds. Evan evaluating a global likeString
takes that amount of time.Log File
vscode-debugadapter-ba3a87b5.json.gz
VS Code Version: 1.72.2
Additional context
I have tried
"sourceMapRenames": false,
but didn't see any change.The text was updated successfully, but these errors were encountered: