(perf) cache fileExists resolutions #1325
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This makes getCompletions perform many times faster, the bigger the project the more it benefits from this cache.
I noticed that there's a lot of time spent in
fileExists
during analyzing whether or not #1192 does make any difference. I then also found that TypeScript does something similar for its watcher at https://github.com/microsoft/TypeScript/blob/1298f498f4cde7fa53cbf050ebfeefdf85c848ec/src/compiler/watchUtilities.ts#L42 , and thatts.sys.fileExists
does not cache anything, so we need to do it ourselves.Should help #1130 and #1139
I also found out during that that we are likely not properly removing Svelte snapshots when its file is deleted. I'll try this out later on.
Another possible speed-up I found was this method in completions, according to the perf analysis some time is spent in that area in total, probably due to source mapping. We could speed that up in this case because the textEdit ranges are probably all the same, so we can create a cache there. Update: I was wrong, textEdit is rarely filled especially when it's about global completions. But I found that we can compute
path
once only becausepathToUrl
is not that fast either.@jasonlyu123 thoughts?