feature request - faster compiler

[sod]

Preamble

What if a build that requires 300 seconds now would be done in 3 seconds instead? Without cache? This currently becomes reality for VDOM based frameworks like vue & react.

With angular it's not that easy, as the framework is basicly a compiler.

🚀 feature request

Faster compiler.

Description

Pretty sure the angular team loves performance and compiler stuff. So I just wanna see what you think about this.

There are currently two typescript to javascript compilers in development:

https://github.com/evanw/esbuild (written in go)
https://github.com/swc-project/swc (written in rust)

In the wild:
esbuild is used by vite - maybe the next official bundler for vue 3
swc is used by deno - a secure alternative to node.js, which natively understands typescript files

The performance is pretty remarkable. The performance gains are in the 100x ballpark. So if your typical webpack + loader written in javascript builds something in 50s, these two do the same in 500ms! So the current javascript based approaches clearly are bottlenecking in what V8 is capable of.

We switched our jest unit tests from ts-jest to swc-jest and the runtime went down from 50s to 11s - pretty much just the compute of executing the suite itself is left, the compile effort nearly disappears. Of course the tests run in JIT mode. If we had an angular compiler that fast, this could be even more swift.

swc in particular may be interesting for angular, as the deno team right now tries to boost the typescript performance if they can just generate the AST via swc. Maybe you could do something similar. Get the AST from swc.

Of course you are google. Maybe V8 just needs some optimizations for parsers. Sure thats not important for browser performance. But so much of the javascript tooling right now relies on V8. If rust or go can do the same task in a 1/100 of the time, there clearly seems to be some low hanging fruit.

[petebacondarwin]

Note that neither of these projects support (or plan to support e.g. swc-project/swc#126) actual type checking the code, which is one of the major benefits of TS. If you are 100% sure that your code is correct then doing the transpile with one of these tools is definitely a win. But the problem is, if you are not sure, you still need to run the TS compiler to check, which defeats the whole point of using a faster transpiler.

[sod]

Thats where a hybrid may be interesting. Generate the AST with swc, and let typescript do the rest. Or the question, why the V8 is 100 times slower.

[petebacondarwin]

Generating the AST is not really the bottleneck in the TypeScript compiler. The type-checking aspects of TSC are by far the biggest performance drain. Anecdotally, in my time spent performance testing TS I would say at least 90% of the effort is checking the typings. So a 100x improvement in parsing would only save ~9% of the total compile time.

I would also expect that even if a non-JS tool was used to generate an AST, the stringifying and then re-parsing of the AST nodes to pass it from non-JS to the TypeScript compiler would negate aspects of that.

That being said, I believe CLI team were considering whether a tool like one of these could be used instead of the JS bundler/minifyer (e.g. webpack/terser). Which would indeed provide a hybrid solution with a fair amount of upside.

[sod]

The performance is hard to believe. You have to try it. But 100x is real. It is switching tsc with diagnostics turned off (!) to either esbuild & swc!

We never ran our unit tests with diagnostics enabled. Why would we? tsc diagnostics can run in a separate process anyway.

jest --no-cache went from 50s to 11s. Where 10.5s of it is actually running the specs. So the compilation pretty much went from 40s to ~500ms. Hugh gain for CI as that always runs with a cold cache.

[sod]

I don't know if I can agree with typechecking being slow. Running tsc --noEmit in our project takes 20 seconds. Where as the build needs 120 seconds.

[petebacondarwin]

I don't know if I can agree with typechecking being slow. Running tsc --noEmit in our project takes 20 seconds. Where as the build needs 120 seconds.

I may be wrong about my numbers - but that was my anecdotal experience. By the way, diagnostics off does not necessarily avoid building the TypeChecker which is what is used to do type-checking. I think it just avoids checking for failures. It is the complexity of the internal data structures of the TypeChecker that take time to compute (i.e. all the ts.Symbol information etc).

---

So your hybrid suggestion would be to run tests (i.e. unit/e2e) in a separate process/job to type-checking. I guess that would allow you to parallelize the type-checking alongside the test runs. Not a bad idea.

[etay2000]

Please don't mention the word 'compiler' to anyone on the Angular team. Next thing you know everything will be put on hold again for years while the latest ** insert trendy name here ** compiler is developed.

[alan-agius4]

So your hybrid suggestion would be to run tests (i.e. unit/e2e) in a separate process/job to type-checking. I guess that would allow you to parallelize the type-checking alongside the test runs. Not a bad idea.

Just to chime in, having type-checking in a separate process doesn’t come free, as the memory consumption will double, because files needs to be cached in 2 different processes.

In Angular CLI we already type-check in a forked process, although with the new Ivy NGTSC plugin which will be used in future versions it will removed as it’s actually slower.

Also as @petebacondarwin mentioned in TSC there is no real way to turn off ‘TypeChecking`.

[ahnpnl]

Just want to chim in because ts-jest is mentioned here. I think the 2 proposed approaches are potential, but I agree that doing hybrid with separate compilation and type checking into different processes will create huge memory consumption.