Ideas for faster cold compiler start-up

Background

For some users, cold compile times are getting to be a bit long - so much so that it’s impacting people’s non-watch-mode experience, and giving people a negative perception of the compiler.

Compilation is already a hard sell for JavaScript users. If we can get some speed wins, I think it’d ease a lot of the pain of starting out with TypeScript.

Automatic skipDefaultLibCheck

lib.d.ts is a pretty big file, and it’s only going to grow. Realistically, most people don’t ever declare symbols that conflict with the global scope, so we made the skipDefaultLibCheck (and also the skipLibCheck flags) for faster compilations.

We can suggest this flag to users, but the truth is that it’s not discoverable. It’s also often misused, so I want to stop recommending it to people. 😄

It’d be interesting to see if we can get the same results of skipDefaultLibCheck based on the code users have written. Any program that doesn’t contribute a global augmentation, or a declaration in the global scope, doesn’t really need to have lib.d.ts checked over again.

@mhegazy and I have discussed this, and it sounds like we have the necessary information after the type-checker undergoes symbol-merging. If no symbols ever get merged outside of lib files, we can make the assumption that lib files never need to get checked. But this requires knowing that all lib files have already had symbols merged up front before any other files the compiler is given.

Pros

• Running with skipDefaultLibCheck removes anywhere between 400-700ms on my machine from a “Hello world” file, so we could expect the same here.

Cons

• We’d have to be careful about our assumptions with this flag.
• Users who edit lib.d.ts wouldn’t see erroneous changes in a compiler (so we’d likely need a forceDefaultLibCheck).
• Ideally, in the absence of edited lib.d.ts files, only our team ever needs to run forceDefaultLibCheck, reducing the cost for all other TypeScript users.

V8 Snapshots

~3 years ago, the V8 team introduced custom startup snapshots. In that post

Limitations aside, startup snapshots remain a great way to save time on initialization. We can shave off 100ms from the startup spent on loading the TypeScript compiler in our example above (on a regular desktop computer). We’re looking forward to seeing how you might put custom snapshots to use!

Obviously my machine’s not the same as that aforementioned desktop, but I’m getting just a bit over 200ms for running tsc -v, so we could possibly minimize a decent chunk of our raw startup cost. Maybe @hashseed or @bmeurer would be able to lend some insight for how difficult this would be.

Minification

@RyanCavanaugh and I tried some offhand loading benchmarks with Uglify and managed

1. to reduce typescript.js’s size by about half
2. to reduce import time by about 30ms

I don’t know how impactful 30ms is, but the size reduction sounds appealing.

[hashseed]

The numbers for the blog post were, as you noted, from 3 years ago. I tested it on the Typescript compiler that was part of the Octane benchmark. I’m sure these numbers are totally outdated, but I’m also sure that the benefits are still very significant.

Unfortunately the steps I used only work on vanilla V8. Node.js currently doesn’t support startup snapshots yet. There are efforts underway to use startup snapshots, but until that is done, custom startup snapshot for e.g. Typescript are not yet possible.

[frank-dspeed]

user snapshot compilation is enabled by node 18 on build https://nodejs.org/en/blog/announcements/v18-release-announce/#build-time-user-land-snapshot-experimental