Strategies for improving incremental Check time?

[bcherny]

Using TS2.1, our build times are painfully slow. This seems to be partially TS's fault, and partially Tsify's fault.

Here is the result of tsc --diagnostics:

Files:           706
Lines:        121760
Nodes:        516136
Identifiers:  167590
Symbols:      265945
Types:         87899
Memory used: 391582K
I/O read:      0.05s
I/O write:     0.15s
Parse time:    1.57s
Bind time:     0.76s
Check time:    5.07s
Emit time:     1.92s
Total time:    9.31s

And 3rd compilation after running tsc -w --diagnostics:

Files:           706
Lines:        121760
Nodes:        516136
Identifiers:  167590
Symbols:      265945
Types:         87899
Memory used: 684821K
I/O read:      0.00s
I/O write:     0.04s
Parse time:    0.25s
Bind time:     0.00s
Check time:    3.54s
Emit time:     0.86s
Total time:    4.65s

Using Tsify + Browserify, each incremental compile takes ~8s (~10s with sourcemaps). There's already an issue tracking this slowness on TSify's end, and I'm looking into ways to improve the bundle stitching time (Rollup, SystemJS, concat, etc.) on our end.

I was wondering what the TS team's advice is for improving Check time more generally. What are common gotchas, and patterns to avoid? Are there specific build flags that are helpful (eg. noEmitOnError)? A coworker pointed out that in Scala and Haskell, adding param and return type annotations to all function signatures yield huge improvements in build times - is this the case with TypeScript too?

Thanks!

Also see #10018.

[RyanCavanaugh]

For example, a coworker pointed out that in Scala and Haskell, adding param and return type annotations to all function signatures yield huge improvements in build times - is this the case with TypeScript too?

True in some places, not true in others. Return type and parameter type annotations will generally make things slightly faster (the first avoids a union type construction in cases where there are multiple return expressions, the second causes contextual typing to do less work); adding type annotations to variable declarations in theory actually slows things down (we have to compute the initializer expression type either way, so an explicit type annotations adds an assignability check).

[bcherny]

@RyanCavanaugh Is that true for incremental compilation, or just for full compiles? Any other tips?

[RyanCavanaugh]

Typecheck results don't carry over during incremental compilation, so anything related to the type system applies equally to both. The difference between the first and later execution times is just warmed cache / JIT and a small number of lazy-init'd things (also I think we may only do lib.d.ts checking on the first compile?).

Another thing you can try is skipLibCheck which should get you substantial gains. Note that it is not safe to always compile with this flag on - your CI server or something should leave it off to make sure you don't break anything long-term.

[bcherny]

Confirmed that skipLibCheck shaved another 1s off the incremental build time, and 2s off the full build time.

What would you look at next? The target is to get incremental build times down under 1s. It seems unreasonable that a 1 line change should take so long to recompile.

[bcherny]

Also see #10878

[bcherny]

Here's some build times I collected for our app. Obviously, these are specific to the way our build pipeline and bundles are set up. Hopefully this helps someone in the future:

Stack	Full build time (s)	3rd run incremental build time (s)
Gulp + Browserify + TSify	37	10
Browserify + TSify	15	6
TSC	9 tsc --diagnostics	4 tsc --diagnostics -w
Webpack	20 webpack	4 webpack -w

In the end, we ended up using Webpack for builds, and driving it with Gulp. This cut our incremental build times in half. Now the bottleneck is TSC's incremental compilation.

[HerringtonDarkholme]

My suggestion is to skip all the type checking in watch mode. You can generally configure this in webpack's loader by options like transpileOnly. And compiling error should be visible in editor so that spotting typos will not be hard during developing.

Then in full build type checking can be turned on again for quality assurance. Caveat: decorator's metadata requires type info so transpiling won't be enough.

[bcherny]

@HerringtonDarkholme That's a really interesting idea! My fear is that without typechecking it will be annoying to catch issues where type changes break file/module interfaces (ie. export A's type changed, breaking module B when it imports A). I'll try it out and report back.

At a higher level, maybe you can help me understand why incremental checking takes so long. If I write some bad TypeScript, VSCode highlights the guilty code in red immediately (<1s). If this is what the "Check" step does during TS compilation, why does it take the TS compiler so long to complete that step, where VSCode does it so quickly?

My mental model is of code as an AST, with types attached to nodes. When a type changes due to a code change:

• At best, just the immediate neighbors of that node in the AST need to be invalidated and re-checked
• At worst, the paths from the changed node to each of its terminal nodes, and from the changed node to the root node need to be invalidated and re-checked

Is this an accurate representation of how TSC incremental compilation works? If so, why does it take so long (time seems to scale with number of types)? If not, how does it actually work? What is cached between incremental compilations, and what has to be recomputed?

[RyanCavanaugh]

The problem is that declarations in one file can affect errors, and emit, in arbitrary other files:

// foo.ts
interface A {
  x: number;
}

// bar.ts
let x: A = { x: 100 };

If we change x: number; in foo.ts to x: string, there is a new error in bar.ts even though that file is unchanged. And there can be indirection here to arbitrary levels.

For emit:

// foo.ts
namespace X {
  // delete me
  export var y = 10;
}

// bar.ts
var y;
namespace X {
  let x = y;
}

When we delete export var y in foo.ts, we need to change the emit of bar.ts.

Fun fact: A previous implementation of TS tried to maintain a reverse mapping of dependencies such that given an invalidated node, you could determine which other nodes needed to be re-typechecked. This never worked 100%. I wrote a tool that iterated file edits and compared this "incremental" typecheck to the "clean" typecheck and produced a log file when the results were not the same; this tool never stopped finding bugs until we just gave up on the approach.

In an editor scenario, when a file is changed, we immediately typecheck the changed file and then check all the other files "later". This is usually faster than you can Ctrl-Tab to another file anyway, so it appears to be instantaneous. Commandline watch compilation doesn't keep track of which files have changed and which haven't.

If you are willing to get your entire project compiling under the isolatedModules switch, then you can safely wire up your build system to do a simple emit of only changed files, which should be practically instant, followed by a re-typecheck.

[bcherny]

Fun fact: A previous implementation of TS tried to maintain a reverse mapping of dependencies such that given an invalidated node, you could determine which other nodes needed to be re-typechecked.

This sounds like the best possible solution! Least possible invalidation, least possible re-checking. The worst case is as bad as it is today, the best case is an order of magnitude speedup, and the average case is still a big speedup.

This never worked 100%. I wrote a tool that iterated file edits and compared this "incremental" typecheck to the "clean" typecheck and produced a log file when the results were not the same; this tool never stopped finding bugs until we just gave up on the approach.

That's a bummer, though I'm sure it was annoying to keep finding bugs for a piece of code that so many people relied on. Do you think you will ever revisit the approach? It seems like a huge win to have lightning fast incremental compiles, and a good way to win over JS devs used to fast compiles (and we could brag to our Scala and Haskell friends).

If you are willing to get your entire project compiling under the isolatedModules switch, then you can safely wire up your build system to do a simple emit of only changed files, which should be practically instant, followed by a re-typecheck.

After enabling compilerOptions.isolatedModules, and awesomeTypescriptLoaderOptions.useTranspileModule, incremental build times didn't seem to change much. This outside the domain of TSC, but do you know if there's another build flag I should enable?

Come to think of it, I don't really understand what isolatedModules is doing. From this comment it sounds like it's forgoing type checks between files (eg. in your 2 examples above, TSC would not complain) - is that right?

As @HerringtonDarkholme mentioned, awesomeTypescriptLoaderOptions.transpileOnly did give a significant speedup, with incremental build now taking ~500ms at the cost of watch mode type safety.

[RyanCavanaugh]

Do you think you will ever revisit the approach?

Unlikely. It made non-incremental compilations much, much slower due to all the extra information that had to be generated and tracked. The rewrite that avoided this approach was 4x faster at non-incremental compilation -- basically, so fast that it could do a full typecheck in the time it took the old system to do an incremental typecheck.

It's also worth noting the current typechecker can "start anywhere" - it doesn't need to do a full walk to compute a type at an arbitrary location. So for example when you type a new expression into a file and hover over it, there isn't a full typecheck needed to compute the type of the expression; we can simply compute what's needed. So in that regard it's nearly the best-of-both-worlds, minus the odd case of wanting to get a complete set of program errors given a small change in one file.

isolatedModules by itself doesn't produce the speedup - it's that a compilation that succeeds under this flag can be safely transpiled by a tool like awesomeTypescriptLoaderOptions.transpileOnly because it's been verified to not have cross-file emit dependencies.

[ORESoftware]

is there a way to just skip type checking for incremental builds? Is there a command line flag for that? All I want for incremental builds is to transpile. Looking in the above comments, is --skipLibCheck the best option for this? I tried it and it seemed to speed up things up about 25% - 30%.

[normalser]

#10879 ?