Type checking is too slow

[keithamus]

On my machine type checking takes at least 18s to execute. This is an extremely long time to wait for feedback and contributes to poor DX. Even with watch mode on, reactions to file saves can take a couple of seconds to catch up. We can see from the extended diagnostics that the problem isn't I/O, as almost all of the total time spent is in Check Time:

Files:                         1677
Lines of Library:             40612
Lines of Definitions:        155849
Lines of TypeScript:          85332
Lines of JavaScript:             77
Lines of JSON:                  153
Lines of Other:                   0
Identifiers:                 324698
Symbols:                     763955
Types:                       527018
Instantiations:             4699321
Memory used:               1104919K
Assignability cache size:    507024
Identity cache size:          22959
Subtype cache size:           39580
Strict subtype cache size:    15258
I/O Read time:                0.07s
Parse time:                   0.92s
ResolveModule time:           0.15s
ResolveTypeReference time:    0.01s
ResolveLibrary time:          0.01s
Program time:                 1.33s
Bind time:                    0.51s
Check time:                  16.91s
printTime time:               0.00s
Emit time:                    0.00s
Total time:                  18.74s

Luckily the TypeScript wiki has some tips on Performance. Also lucky for us, we seem to have low hanging fruit in almost every area where they claim performance costs can add up, including:

• Preferring intersections over interfaces.
• Relying a lot on inferrence.
• Relying on a lot of unions.
• Introducing complex types without properly annotating them.

I think some fairly simple changes can be made to the codebase to speed up check time. And we can persist this changes by enabling lint rules like @typescript-eslint/explicit-function-return-type.

[siddharthkp]

That's surprisingly long! Do you get instant feedback in your editor or do you have to wait more than 1-2 seconds for that as well?

[iansan5653]

As another data point, I see similarly long times in Codespaces:

$ time (npm run type-check -w @primer/react >> dev/null)

real    0m22.054s
user    0m34.194s
sys     0m1.221s

That said, I haven't noticed issues with the VSCode extension; incremental checking in that form seems to work pretty quickly.

We are talking about over 85k lines of TypeScript -- I'd be interested in knowing what 'typical' tsc performance looks like to see if/how bad our code really is, vs just the typechecker not being that fast in general. (Although even if we're seeing typical times, there's still no reason not to try and get some performance gains if it's not too much effort and doesn't require sacrificing code quality)

[joshblack]

Definitely all for improving performance 👍 Would be great to know what's the floor performance-wise for a project this size along with what the effort would be to get there 👀 When it comes to simplifying types, another possible benefit for this could be improved docgen on the storybook side if they're easier to infer which would be great.

Random, is it possible to profile the project and see which files or types are contributing the most to the check phase?