Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

10x compiler performance #38573

Closed
newtack opened this issue May 14, 2020 · 7 comments
Closed

10x compiler performance #38573

newtack opened this issue May 14, 2020 · 7 comments
Labels
Unactionable There isn't something we can do with this issue

Comments

@newtack
Copy link

newtack commented May 14, 2020

Typescript is awesome. While I am sure there are more features that may still be added, the main pain point I have right now in terms of usability is that compilation speed makes me wait on a medium sized project (~ 45K lines of Typescript).

Typescript compilation speed also is a bottleneck in Deno, which was just released, see https://deno.land/v1#tsc-bottleneck

If we could have one feature that would make Typescript much better, it would be 10x compiler speed.

While incremental improvements should be considered, I think it is time for the team to really look at what would be needed to 10x compiler speed.

Going with Rust/wasm and a massively parallel (web worker?) approach may be able to get us there.

@nmain
Copy link

nmain commented May 14, 2020

The team is constantly monitoring performance of the compiler and impact of new changes on performance. An entire order of magnitude of speed difference though? That's not something you can pull out of a hat.

@RyanCavanaugh RyanCavanaugh added the Unactionable There isn't something we can do with this issue label May 14, 2020
@RyanCavanaugh
Copy link
Member

Are people under the impression that we haven't thought about this already? 😕

@newtack
Copy link
Author

newtack commented May 14, 2020

@RyanCavanaugh I wasn't aware of it. :-)

But, with Deno 1.0 being released and them wanting a Rust based compiler, rather than having many different teams (Typescript/Deno/swc/etc.) working separately on it, it would be great if this could be a joined effort.

@RyanCavanaugh
Copy link
Member

Engineering teams at Microsoft are aware of the concepts of rewrite and native languages, I assure you.

@sod
Copy link

sod commented Sep 7, 2020

The swc developer seems to literally try to add tsc capabilites right now, see
swc-project/swc#889 (d.ts generation) & swc-project/swc#571 (type checking)

The amount of source code he/she produces in a given day is mind boggling.

The performance is incredible. When I replace the typescript compiler from tsc to swc for our jest test suite, the runtime shrinks from 50 seconds to 11 seconds. Where from the 11 seconds actually 10.5 seconds is running the suite. So the compilation time goes from 39 seconds to 500ms.

Deno switched a month ago from tsc to swc if you start via --no-check via denoland/deno#6895 and they saw a two magnitude faster compile time. Right now they seem to investigate if they can feed the AST from swc to typescript to speed up type checking as well.

@JohanHeyvaert
Copy link

JohanHeyvaert commented Aug 24, 2021

Especially for unit testing a monorepo the typescript compilation is too slow. Therefore the people from WallabyJS advise to try swc. Cf. https://wallabyjs.com/blog/optimizing-typescript.html

Hopefully the official compiler can learn something from swc?

@Bessonov
Copy link

From my point of view, bet on alternative compiler is very dangerous. TypeScript is too complex and too powerful language. BTW, I'm not sure that swc will stay free. I can throw sucrase in. Interesting point about sucrase is, well, it's ts/js based and (possibly) faster than rust-based swc.

I think there are different use cases of slowness. For example, in most cases slow compilation CI is not good, but OK. While slow compilation during development is very annoying. Currently, I use webpack 5 with caching(!) + ts-loader + fork-ts-checker + devServer/nodemon. And it works fast enough. Additionally, vscode do own checks. I will love to have more reliance on vsc and get rid fork-ts-checker during development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unactionable There isn't something we can do with this issue
Projects
None yet
Development

No branches or pull requests

6 participants