GeezerVison

Restores (and improves upon) the behavior introduced in #31893 without the significant performance regression by adding several caches. (Closes #32441.)

Diff compared to original PR (trying to keep changes to master out of it but will fall behind every now and then)

Note: comments about performance and bugs and changes in the thread below are talking about various states during the draft lifetime of this PR. This PR description reflects the state as of the time I’m changing it from “Draft” to “Ready for Review,” August 26 at 12:00 PM PDT.

Performance impact of this PR

TL;DR: Disregarding the very first completions request made to TS Server, the worst-case completions request is 28% slower than before. But, getting the completions list plus completion details is only 1% slower at worst, and typical requests are 76–80% faster thanks to some added caching.

There are two language service operations to consider:

1. getCompletionsAtPosition returns an array of available completions without much detailed info about each.
2. getCompletionEntryDetails is called for a specific entry from the results of the former operation, and gets more details about that completion, like JSDoc, symbol display parts, and CodeActions that will occur.

In VS Code, the completion list UI appears after the former returns. The latter is then called in immediate succession, and its response inserts more details into the same UI. So, the duration of getCompletionsAtPosition is a lower bound of UI response time, but the sum of the two calls affects perceived responsiveness since the UI doesn’t settle until both are complete.

I measured response times before and after this PR in a large project and took the average of 5 samples of each type of measurement reported here. In reporting timings for cached calls, I’ll report “Aug 10 Nightly” as “N/A” to indicate that the original code base performed no caching, but I’ll use the uncached timings to calculate the percent difference, since those would be the timings measured in identical scenarios.

^1. The package.json cache is populated upon the first request that uses it, and future changes to package.json files update the cache eagerly. In other words, this number only ever happens on the very first completions request that a project receives.
^2. Cache lives for the duration of editing a single file, except after edge-case edits to that file that modify modules visible to the program.
^3. Cache lives while the program is identical, which happens frequently for details, e.g. when navigating the completion list with arrow keys to view details of other items. The only time details requests trigger without a cache is after typing rapidly, such that previous requests get canceled.
^4. The worst-case scenario for this PR is a cold cache (nothing in the lifetime of the language service has yet requested package.json information) followed by a cached details call. They can’t both be uncached, because the former populates the cache of the latter. The cache could be invalidated by continuing to type quickly, but at that point the original cold request for the list would be canceled too, and the next call would use the cached package.json.

Implementation

Even the absolute worst measurement of 56% slower is much better than #31893, which was ~12,000% slower. Here’s what made the difference.

Caching symlinks discovery

Getting the best module specifier to use from one module to another requires determining if there are any symlinks hanging around. The original PR tries to get the module specifier for every possible auto-import in a loop, which re-ran the symlink discovery code every time. But, the inputs to that code are constant over that loop, so it needs only be run once. This PR introduces a function moduleSpecifiers.withCachedSymlinks that uses a constant set of symlinks within a callback. This alone brought the performance impact down from ~12,000% slower to ~100% slower.

Caching package.json content

The previous PR searched for and read package.json files from disk during each request. This PR adds:

1. A cache that keeps track of what folders definitely don’t have a package.json file to avoid reading directories
2. A cache of package.json dependencies for a folder where a package.json file was previously found
3. An added function in an existing directory watch that invalidates 1) and 2) when a package.json has been added or removed within the project
4. An additional watch on any package.json file found (outside of node_modules) to invalidate 2) when the content changes.

Sheetal Nandi (@sheetalkamat) suggested replacing the additional package.json watch with an existing directory watch that detects changes to node_modules. I tried this approach, but it's quite common to run npm install --save dep when dep was already in node_modules required by something else, or npm uninstall --save dep when dep is still required by something else. In these cases, package.json changes, but node_modules does not.

Caching the auto-import list itself

Generally, the auto-imports available to a particular file don’t change while editing that file alone. So, we now cache auto-imports, and invalidate them when:

1. A different file requests auto-imports
2. The same file adds or removes an import or triple-slash reference that changes the modules in the program
3. The same file adds or removes an ambient module or module augmentation
4. The same file edits the contents of an ambient module or module augmentation
5. The same file has ATA enabled, has acquired @types/node via ATA, and makes an edit that causes it to have imports of node core modules when it didn’t before, or vice versa. The same logic introduced in Proposal: If there’s a package.json, only auto-import things in it, more or less #31893 about inferring whether to offer node core module auto-imports still exists, so the cache needs to be invalidated when the input to that inference changes. (Note: I plan to make this inference smarter in a later PR—didn’t want this one to balloon in scope more than it already has.)

Caching auto-imports for completion entry details

Completion details display type information, so they can’t be as aggressively cached as the list of auto-imports available. But, completion details are commonly requested when the program hasn’t changed at all, so the same cache used for the auto-import list described above can be used for completion details requests if the project version hasn’t changed.

Avoiding computing the full specifier for a node_modules module

When determining whether a module that can be referred to by some node_modules-style path e.g. import 'foo/lib/whatever' should be filtered out by a package.json file or not, the path after foo/ is irrelevant. The previous PR used an existing function that calculated the entire path, which requires FS operations (to look for a dependency’s package.json and find a types entry). To avoid unnecessary FS operations, this PR adds an option to that function (tryGetModuleNameAsNodeModule) that prevents it from calculating the full path.