TypeScript Extremely Slow

[omidkrad]

This problem is killing us. Our TS node project started being mind-bogglingly slow since a few days ago and it's hindering our work. I found out as long as I have no @types\* modules installed, it works fine but as soon as I add any @types module, such as @types/bluebird it gets slow.

When all type modules are removed, tsc takes about 5 sec to complete (obviously with a lot of errors). With type modules installed, it takes about 30 sec and with typescript@next is it about twice as slow.

Here are the diagnostics stats:

tsc version 2.6.2

Files: 227
Lines: 140932
Nodes: 569637
Identifiers: 209088
Symbols: 1071525
Types: 849139
Memory used: 906107K
I/O read: 0.02s
I/O write: 0.02s
Parse time: 1.82s
Bind time: 0.68s
Check time: 26.49s
Emit time: 1.77s
Total time: 30.76s

tsc version 2.7.0-dev.20180116

Files: 228
Lines: 141263
Nodes: 571047
Identifiers: 209620
Symbols: 2169856
Types: 1077202
Memory used: 1156922K
I/O read: 0.04s
I/O write: 0.03s
Parse time: 1.81s
Bind time: 0.67s
Check time: 51.69s
Emit time: 2.20s
Total time: 56.36s

Here are the type modules that we use:

npm install @types/bluebird @types/body-parser @types/bunyan @types/chai @types/continuation-local-storage @types/cookie-parser @types/download @types/express @types/express-serve-static-core @types/form-data @types/geojson @types/googlemaps @types/lodash @types/long @types/mime @types/moment-timezone @types/morgan @types/nconf @types/node @types/node-geocoder @types/query-string @types/reflect-metadata @types/request @types/request-promise @types/sequelize @types/serve-static @types/stripe @types/twilio @types/validator --save-dev

Also in VSCode, CMD+Click on symbols takes a long time to resolve and when running TS Build Task sometimes we get this error:

CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Do you have any suggestions how we can fix this problem?

[mhegazy]

I think there is something else going here.. locally here is what i see:

c:\test\21221>tsc --v
Version 2.7.0-dev.20180116

c:\test\21221>tsc --diagnostics
Files:            36
Lines:         72104
Nodes:        292746
Identifiers:  105066
Symbols:       79907
Types:         28453
Memory used: 127961K
I/O read:      0.01s
I/O write:     0.00s
Parse time:    0.85s
Bind time:     0.40s
Check time:    1.68s
Emit time:     0.02s
Total time:    2.95s

c:\test\21221>node c:\releases\2.6.1\tsc.js --v
Version 2.6.1

c:\test\21221>node c:\releases\2.6.1\tsc.js --diagnostics
Files:            36
Lines:         71852
Nodes:        288906
Identifiers:  103737
Symbols:       79674
Types:         28318
Memory used: 129399K
I/O read:      0.02s
I/O write:     0.00s
Parse time:    0.90s
Bind time:     0.45s
Check time:    1.66s
Emit time:     0.02s
Total time:    3.03s

This seems like within the margin of error. I think there is something specific about your project that is triggering the slow down, and we would love to know more.

Thinking of things that changed between 2.6 and 2.7 is the addition of a new --strict flag. if you are running under --strict, ensure the new flag --strictPropertyInitialization is set to false and try again with the diagnostics.

the other is try the same compilation with --skipLibCheck, though I do not see this locally.

[mhegazy]

Our TS node project started being mind-bogglingly slow since a few days ago

Try to bisect your own code changes and find the commit where it started to be slow, this might help us identify the source of this slowness..

also check if any new @types package was added, or a new version of an @types package that you depend on was updated, that might be a pointer to what is causing the slowness.

[omidkrad]

It is slow now even when we go back in history. We suspected it happened after vscode upgrade, but we're not sure. I can put together a project that reproduces the slowness and share it with you by email if you can take a look.

[mhegazy]

sure. email is my github username @microsoft.com

[omidkrad]

I have problem creating a repro, when I trim it down it compiles fast. I can't share the whole project, but if I could make a barebone repro I will send it over for you to examine. Does a TS project generally run slower when it has many errors? This is a project we're converting from JS and going through a lot of errors to fix. I'm guessing maybe it gets faster when all errors are resolved?

[mhegazy]

Does a TS project generally run slower when it has many errors?

if you have errors in the order of 10,000's then yes. creating the error message generates garbage, so generating many of these can generate memory pressure on the GC, and thus more execution time.

This is a project we're converting from JS and going through a lot of errors to fix.

One common issue we see is the compiler picking up files (based on include/exclude patterns) the user did not intend to include. Run tsc --listFiles --p <tsconfig.json> to see all the files the compiler is picking up for your project.

I'm guessing maybe it gets faster when all errors are resolved?

I would not assume errors are the cause of slow down. chances are, 1. too many files included in the compilation (you can fix that by adjusting your include/exclude patterns), 2. some type relation is expensive to check (we need to know what is going on, chances are it is a compiler bug), or 3. some auto-generated .js/ minified .js file with complex control flow graph that the compiler is spending too much time analyzing (you can fix this by excluding the file and including a .d.ts file for it).

[omidkrad]

@mhegazy thanks a lot for your detailed response. I think our problem is gone for now after we decided to rename all .js files to .ts. It's a lot faster now and the incremental compilations work as expected. So I will go ahead and close this issue.

In case it helps anyone, I used the following PowerShell command to do a batch rename:

gci -recurse *.js | ? { $_ -notlike '*/node_modules/*' } | % { git mv $_ ($_ -replace '\.js$', '.ts') }