Avoid caching resolved signatures for language service requests like signature help#52679
Conversation
… their signatures
src/compiler/checker.ts
Outdated
| getResolvedSignatureWorker(node, candidatesOutArray, argumentCount, CheckMode.Normal), | ||
| getResolvedSignatureForStringLiteralCompletions: (call, editingArgument, candidatesOutArray) => | ||
| getResolvedSignatureWorker(call, candidatesOutArray, /*argumentCount*/ undefined, CheckMode.IsForStringLiteralArgumentCompletions, editingArgument), | ||
| runWithoutResolvedSignatureCaching(call, () => getResolvedSignatureWorker(call, candidatesOutArray, /*argumentCount*/ undefined, CheckMode.IsForStringLiteralArgumentCompletions, editingArgument)), |
There was a problem hiding this comment.
perhaps this blocking wrapper should be moved to getResolvedSignatureWorker (to be called conditionally)? I didn't want to incur a closure penalty there though (maybe that's negligible?)
There was a problem hiding this comment.
Does it need to be conditional? Currently 2 out of 3 callers of getResolvedSignatureWorkers need to skip the cache, so I suspect that the 3rd caller also needs to. It's worth checking out and trying.
The wrapper-like nature of runWithInferenceBlockedFromSourceNode might also be better if inlined, although it's used in getContextualType as well. I would inline and duplicate the wrapper functions to see if it looks better (and perhaps, runs faster).
There was a problem hiding this comment.
Does it need to be conditional? Currently 2 out of 3 callers of getResolvedSignatureWorkers need to skip the cache, so I suspect that the 3rd caller also needs to. It's worth checking out and trying.
The 3rd call doesn't look LSP-related - more like a type-checking one. So I assumed that this one doesn't need this and might actually don't want this as for "real" type-checking purposes we want to cache things.
Admittedly, I confused myself and thought that getResolvedSignatureWorker is the getResolvedSignature (*Worker functions are often used within the "core" type checking algorithm) and that the "core" type checking calls into that. I considered this to be a hot path and thus wanted to avoid adding extra things there.
The wrapper-like nature of runWithInferenceBlockedFromSourceNode might also be better if inlined, although it's used in getContextualType as well. I would inline and duplicate the wrapper functions to see if it looks better (and perhaps, runs faster).
Since this blocking~ is only relevant for LSP requests - does perf matter that much here? I would consider this to be less of the hot path (maybe I'm wrong though) and wouldn't be bothered as much with inlining and comparing perf. Let me know what you think.
sandersn
left a comment
There was a problem hiding this comment.
Nice fix for a tricky bug! Couple of suggestions.
src/compiler/checker.ts
Outdated
| getResolvedSignatureWorker(node, candidatesOutArray, argumentCount, CheckMode.Normal), | ||
| getResolvedSignatureForStringLiteralCompletions: (call, editingArgument, candidatesOutArray) => | ||
| getResolvedSignatureWorker(call, candidatesOutArray, /*argumentCount*/ undefined, CheckMode.IsForStringLiteralArgumentCompletions, editingArgument), | ||
| runWithoutResolvedSignatureCaching(call, () => getResolvedSignatureWorker(call, candidatesOutArray, /*argumentCount*/ undefined, CheckMode.IsForStringLiteralArgumentCompletions, editingArgument)), |
There was a problem hiding this comment.
Does it need to be conditional? Currently 2 out of 3 callers of getResolvedSignatureWorkers need to skip the cache, so I suspect that the 3rd caller also needs to. It's worth checking out and trying.
The wrapper-like nature of runWithInferenceBlockedFromSourceNode might also be better if inlined, although it's used in getContextualType as well. I would inline and duplicate the wrapper functions to see if it looks better (and perhaps, runs faster).
|
@sandersn @DanielRosenwasser I pushed out some changes to the structure of the code. Overall, I don't think we need to juggle things more - but that's subjective. Yes, there is some duplication of the work done in |
andrewbranch
left a comment
There was a problem hiding this comment.
Very excited to have this fixed 🌟
|
@typescript-bot pack this |
|
Heya @DanielRosenwasser, I've started to run the diff-based user code test suite (tsserver) on this PR at 7b79e1a. You can monitor the build here. |
|
Heya @DanielRosenwasser, I've started to run the diff-based top-repos suite (tsserver) on this PR at 7b79e1a. You can monitor the build here. |
|
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 7b79e1a. You can monitor the build here. |
|
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running |
fixes #49624
cc @andrewbranch