Before TypeScript can respond to any semantic query (accurately), the entire program has to be loaded into memory, parsed, and bound. Parsing today ends up taking a surprising amount of time, and even if we don't have to do any path resolution. One of the things we could exploit is that parsing any two files should (ideally) be independent operations - and so one could imagine spinning up multiple processes or workers to divide and conquer the problem.

Unfortunately, program construction is not an embarrassingly parallelizable step because we don't always know the full list of files in a program ahead of time; however, one could imagine some work-stealing scheme with single orchestrator.

A glaring problem for TypeScript is that it is currently synchronous from end-to-end, and most worker capabilities are built with an expectation of asynchronous communication (and often depend on the surrounding environment - Node.js main thread, UI thread in the browser, non-UI worker threads, etc.). Another problem is that while we might be able to divide and conquer, the overhead of moving data between workers might be more than we'd have anticipated. And one last concern I'll mention is that while running multiple workers gets more work done faster, it's not a free lunch - it has UX tradeoffs because multiple threads can degrade the responsiveness of the overall machine.

So in the coming months, we'll be investigating here, finding out what works, and seeing if we can bring it into TypeScript itself.