Make the Compiler and Language Service API Asynchronous

It makes very little sense that IO-bound operations (e.g. readFile, writeFile) are synchronous when we run on a platform whose touted strength is in writing IO-bound applications through asynchronous non-blocking APIs.

Compile times could probably be shaved down by a bit, especially for large projects with many files. Additionally, tooling experience should be as responsive as possible and avoid blocking in the event that IO takes place, enabling several optimizations to free memory on the managed side.

With #1664, this should be significantly easier.

This means that at the very least, the following would change to have asynchronous counterparts.

• createSourceFile (because of /// <reference ... /> comments)
• createProgram
• all of the language service API

[felixfbecker]

This issue hasn’t been active for a while, but I wanted to share our use case nevertheless. I am working on the TypeScript support for Sourcegraph. You can explore code online with code intelligence, eg https://sourcegraph.com/github.com/Microsoft/TypeScript.

Initialization time (the time from the visit of the page and the first showing hover) is a high priority for us, and atm it definitely is not where we want it to be. For something simple as a hover over a local symbol in a file, we need to do a full checkout of all the TypeScript files in the repo, read them into memory just to be able to provide them synchronously - no matter what files are actually needed. This is exactly what @CyrusNajmabadi described for VS in https://github.com/Microsoft/TypeScript/issues/1857#issuecomment-99315295.

To add to what Cyrus said, I think it would generally be helpful to see some data regarding this before we came to any sort of conclusion - both on the compiler side as well as the LS side.

I can ensure you that fetching all files from an external git service instead of on-demand per-file is a huge difference. Installation of dependencies also counts into this, since again, we might need these files (we all know how long a fresh npm/yarn install can take). I would be happy to provide concrete numbers if that helps.

what I am saying is this should be done as part of other work items. We need to do scalability and performance work items, but these are not scheduled… So all I am saying is close this issue, and when we start looking into these work items (possibly as we are doing P2P) see what are our options and what we need to do…

all of our language support is backed by the language server protocol, and we currently use one that wraps the TS service. Having this would make implementing LSP (#11274) almost trivial.

we still can use the ts server, which can Handel most of the io.

That is fine in a desktop environment, but not in a distributed system where the files are not available on the local file system for example

[CyrusNajmabadi]

@mhegazy This is already an issue for the VS case today. Right now we end up having to load up all files on the VS side before we can even call into the script side to answer a question. We do this so we have the data ready when the LS asks the host “what has changed between these files?” And we have to do this, even though the LS might not ever ask that question (because the version hasn’t changed). If we were async through-and-through, we wouldn’t have this problem.

We’d simply call into the script LS. It would synchronize info with the host, and then the LS would just ask for the changes to files with different versions in an async manner. This would be much better, and would provide a lot less stress on the managed side (for example, Roslyn could flush these files to their cache, instead of having to keep them all in memory.).