Cache file existence in synchronizeHostData

[amcasey]

Saves 1-2% during mui project load (on Linux), mostly by eliminating duplicate non-existence results.

[amcasey]

In very round numbers, I'm seeing updateGraph time drop from 5900ms to 5700ms.

[sheetalkamat]

Is there a reason you are not using changeCompilerHostLikeToUseCache

[amcasey]

I coded it up that way, but found it confusing because of the interaction with HostCache. changeCompilerHostLikeToUseCache covers

1. readFile, which is already handled, slightly differently, by HostCache
2. fileExists
3. directoryExists
4. createDirectory, which would not be used
5. writeFile, which would not be used
6. getSourceFile, which the caller has to decide to hook up or not and overlaps with HostCache

Some of the nuances, e.g. readFile vs readFileWithCache, felt like they would be confusing in this specialized context.

I believe the HostCache is also used in a few places that consume the language service host, rather than the compiler host.

If you feel strongly about it, I can try to rewrite it in a way that eliminates HostCache altogether, in favor of mutating the host directly.

[sheetalkamat]

I am just wondering if we can get rid of host cache and use our standard method so that if any additions or changes we do in future are not missed? Looked at fileExists , readFile etc in services and its used for duration of program creation so would prefer to use compilerHost and changeCompilerHostLikeToUseCache instead of maintaining our own caches..

[sheetalkamat]

I am just wondering if we can get rid of host cache and use our standard method so that if any additions or changes we do in future are not missed? Looked at fileExists , readFile etc in services and its used for duration of program creation so would prefer to use compilerHost and changeCompilerHostLikeToUseCache instead of maintaining our own caches..