TypeScript build is slow, compileOnSave/--watch taking ~1minute

[bforsythe]

Hi all, first I'll say our team has been big TypeScript fans for a while now (pre-2.x)! But unfortunately, performance issues have been getting rough, and some people on the team are starting to feel that the type safety isn't worth the substantial build time increase (perhaps a little hyperbolic, but it's definitely frustrating).

First off, here's the diagnostic output:

node_modules.bin\tsc -project web/tsconfig.json --diagnostics
Files: 2771
Lines: 205202
Nodes: 934381
Identifiers: 308819
Symbols: 233717
Types: 57830
Memory used: 1191180K
I/O read: 0.91s
I/O write: 0.17s
Parse time: 4.99s
Bind time: 4.46s
Check time: 14.12s
Emit time: 30.09s
Total time: 53.67s

And here's our tsconfig.json:

{
"compileOnSave": true,
"compilerOptions": {
"allowJs": false,
"allowSyntheticDefaultImports": true,
"module": "none",
"noEmitOnError": true,
"noImplicitAny": false,
"sourceMap": true,
"target": "es5",
"outFile": "./path/to/our/outfile.js",
"declaration": true,
"removeComments": true,
},
"include": [
"Content"
],
"exclude": [
"./path/to/our/outfile.d.ts",
"node_modules"
]
}

Other things worth noting:

1. We still have a significant amount of .js files in our solution
2. We are still using namespaces and a single outfile for the vast majority of our files. We have made a small push to start writing modules, but it's pretty painful to mix the two (who loves shim files? No one), and we have too much code to rewrite everything, so it's been slow going.

If there's anymore information I can provide, please let me know, or if you have any thoughts or suggestions we can try, I'd love to hear them! The switch to TS has been the number 1 development/debugging time-saving measure we've made since I've been here. But now it feels like those savings are being reclaimed by the build times :(

Thanks for your help,
Brandon

[sheetalkamat]

Since you have "outFile": "./path/to/our/outfile.js", in your config file, there wont be any incremental build benefit since every time we need to emit all files. Hence till you move away from single file output, the perf is going to be similar to first time compile.

[mhegazy]

performance issues have been getting rough

we would like to know more about the regressions you are having..

[bforsythe]

Thanks for the response @sheetalkamat ! So is moving to modules and using webpack probably going to be the best solution to this? We've got over 2700 TS files, so turning everything into modules is going to be a process.
Or if we come up with a way to get all the individual JS files included on our pages, do you think just killing the single outFile would be a good step (we were worried about the number of requests that might be performed loading a given page, as well as potential ordering concerns that the TS compiler might take into account when generating the outFile, that we would have to keep in mind when doing our <script> includes)?

Thanks again,
Brandon

[bforsythe]

Thanks for the response @mhegazy , we believe that this is mostly an issue of scale, but we haven't really been able to say 100%. I checked a few of our smaller projects with 10's of typescript files vs. our main projects' thousands, and --watch is fairly reasonable using a single outfile (a few seconds).

When I said 'performance issues have been getting rough', I just mean over the past few months of feature development (and adding TS files), the build time seems to be getting worse in a more-than-linear fashion. That could be objectively false (I haven't run any tests), but the general consensus around the office is that a few months ago, compile on save worked fine, and now it's not really usable (and granted, we've added hundreds of ts files since then). In that same time frame, we upgraded to VisualStudio 2017, started using tsconfig's instead of the csproj settings, and then just recently moved away from using MsBuild for Typescript compilation entirely, instead using node_modules/typescript, so there are definitely a number of variables potentially at play. That's why we figured we'd start this thread so we can get a better idea of what we're doing wrong and how we should move forward :)

If there's any more info you'd like, please let me know!
Thanks,
Brandon

[sheetalkamat]

@bforsythe Yes moving away from --out will give you partial benefit as we would then be able to emit only single file if the change doesn't impact the signature. (This is because you have code with "module": "none", and is suppose to be global code and not modular, correct?). So changing contents of function (without changing its signature) will give you benefit of only emitting that file, but if you change the function signature thats global we will emit all files since that would right thing to do. Note that, every change would need to do complete type checking since the semantic diagnostics cant be cached in global code.

[mhegazy]

We would like to take a look at your project and see why compile-on-save is taking too long. but as @sheetalkamat noted, the compiler needs to build all files, and concatenate the output in a single string every time you save, and there is less room for optimization there.

[bforsythe]

@mhegazy I'll need to run that by my manager, I'll get back to you tomorrow morning. Is there a secure way I can send it?

Thanks,
Brandon

[devuo]

In my team we're seeing the same thing with initial compilation times take ~1 minute from 6-8 seconds. We had to rollback to 2.7 in order to have acceptable initial compilation times.

[sheetalkamat]

@devuo Can you please share the code to investigate this. We can sign NDA if needed.

[sheetalkamat]

Closing this bug since this was technically question. If anyone running into issues like slow build, please open new bug with detailed logs. Thanks