-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Add cache to auto-import package.json filter #52422
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
Add cache to auto-import package.json filter #52422
Conversation
@typescript-bot perf test this |
Heya @andrewbranch, I've started to run the perf test suite on this PR at 638dd64. You can monitor the build here. Update: The results are in! |
@andrewbranch Here they are:
CompilerComparison Report - main..52422
System
Hosts
Scenarios
TSServerComparison Report - main..52422
System
Hosts
Scenarios
StartupComparison Report - main..52422
System
Hosts
Scenarios
Developer Information: |
@typescript-bot user test tsserver |
Heya @DanielRosenwasser, I've started to run the diff-based top-repos suite (tsserver) on this PR at 638dd64. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the diff-based user code test suite (tsserver) on this PR at 638dd64. You can monitor the build here. Update: The results are in! |
@DanielRosenwasser Here are the results of running the user test suite comparing Everything looks good! |
@DanielRosenwasser Here are the results of running the top-repos suite comparing Something interesting changed - please have a look. Detailsbackstage/backstage
|
Cool, it does look like this gives a 5% improvement to completions on xstate! |
let ambientModuleCache: Map<Symbol, boolean> | undefined; | ||
let sourceFileCache: Map<SourceFile, boolean> | undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we typically use the symbols or nodes themselves as cache keys; all caches I've dealt with or added use symbol/node IDs instead; not sure if that's intentional or not, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this should be ok now that we are using native maps and life of this cache is well maintained..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does make me wonder if we'd gain anything by switching all of the other caches to work directly...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a vague memory of someone saying using the object instead of ids is preferred now. But I don’t know if there’s a real difference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can @rbuckton or @DanielRosenwasser advise on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Node IDs are set to 0
unconditionally, and set lazily when we need to use a Node
in a Map
or WeakMap
. I tried to remove some usages out of the compiler and didn't find a ton of wins.
The biggest risk here is that you keep a PackageJsonFilter
around across language service operations - leading to either a memory leak, or corrupt state. A WeakMap
works, but I'd rather we just be a little careful about how we use these.
So I agree with Sheetal - the cache doesn't escape so we should be okay with these - just make sure the PackageJsonFilter
object doesn't either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, let me rephrase that - using objects/sparse arrays over Map
s actually is a win, but not if you rely on iteration order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this object only lasts a single request.
I was debugging another issue and noticed that during completions, we go through some work to generate the module specifiers for every export within an ambient module, when obviously that work only needs to be done once per module, not once per export. It made it a pain to debug module specifier generation since I was hitting a breakpoint in one of those functions called with the same inputs over and over, but apparently that work is quite cheap, because I can’t see any appreciable difference locally. Figured I would run the server perf tests though.