7 ms·

TypeScript team released an explorer for performance tuning

111 points by aabbcc1241 3y ago

muglug 3y ago
This is really impressive work, which can benefit other large JS tools. I realise this is sort of a dead horse, but rewriting the Typescript checker in Rust would not be an impossible task for a team as well-resourced as Microsoft’s. I know, because I rewrote a different 100KLOC typechecker myself in Rust (making a few small adjustments for a slightly different target language). It took me about a year. It would speed up the TypeScript typechecker at least 3-5x, which would save a lot of programmer time (and also datacenter energy consumption). There’s one obvious downside — it raises the bar for outside contributions — but given the expertise necessary to contribute usefully to a static analysis tool in the first place, and to contribute to TypeScript in particular, I’m not sure it’s a big additional impediment.
- josteink 3y ago
  A benefit of the typescript compiler being written in typescript is that the compiler-makers get to dogfood their own language. Rewriting it in rust would remove that important aspect c
  - AntonCTO 3y ago
    Rust alone wouldn't help. TypeScript is very hard to compile and to understand because of its complexity. I think there is a need for a different architectural approach with huge parallelization. Some (CI) servers have plenty of cores. Heck, my laptop has 20 threads.
    - wffurr 3y ago
      swc and tsx are already significantly faster than tsc, partly due to being written in faster languages, or languages that make it easier to write fast code with minimal runtimes.
      - AntonCTO 3y ago
        Do they check types? Sorry, my previous comment wasn't very clear. Of course, faster languages produce faster results. But the language alone isn't enough in this case.
      - explaininjs 3y ago
        Neither of those check types. It’s easy to be fast when all you’re doing is filtering out type-bytes (and perhaps some transpiling). That’s nothing compared to actually type checking, which requires solving complex satisfiability problems across the entire codebase.
        muglug 3y ago
        My understanding was that TypeScript would be more parellisable than Flow, which itself is plenty parallelisable: https://arxiv.org/pdf/1708.08021.pdf https://arxiv.org/pdf/1708.08021.pdf
        explaininjs 3y ago
        Call me crazy, but I prefer single threaded. It limits the potential impact on the rest of the system, and all cloud payment is by the core•hour anyways.
    - muglug 3y ago
      The approach is simple (I've implemented it, and so have many others): It takes three steps. Steps 1 and 3 are parellisable, and 2 should be very quick: 1. Convert every file in the repository to an AST, and perform static reflection on that AST. 2. Calcuate the inheritance graph for all the functions, classes etc. you've collected 3. Analyse every file, using the pre-calculated list of functions and classes available in each case.
  - muglug 3y ago
    Yeah, that helps them stay close to the community and prevents any air of superiority that can come from writing Rust. But, while I’m sure it was really important initially, there are now very many test cases and early-adopters to help prevent regressions. And they still have that large TypeScript codebase to test their new tool on — it wouldn’t vanish.
  - wffurr 3y ago
    Doesn’t seem worth the lost performance for the millions of Typescript users.
    - HPsquared 3y ago
      May give an incentive to improve the performance
      - mort96 3y ago
        Which they'd have to do through rewriting it in a faster language.
- latchkey 3y ago
  > I know, because I rewrote a different 100KLOC typechecker myself in Rust (making a few small adjustments for a slightly different target language). It took me about a year. It sounds like you could easily have a nice consulting gig for Microsoft.
- comex 3y ago
  Note that there’s at least one TypeScript type checker being developed in Rust by a third party: https://github.com/dudykr/stc https://github.com/dudykr/stc
DanHulton 3y ago
This is... good news, but I still cannot fathom using the default Typescript compiler for regular development. Seriously, leave the type-checking to your IDE and CICD chain, and switch to using tsx (https://www.npmjs.com/package/tsx https://www.npmjs.com/package/tsx) or swc (https://swc.rs/ https://swc.rs/) and you will _immediately_ notice the difference in speed and productivity.
- herpdyderp 3y ago
  I wish there was also a much faster type checker!
  - vlovich123 3y ago
    I have absolutely 0 problems with the type checking that VSCode does. Always feel snappy. By comparison, command line performance is absolute crap though. The missing piece I suspect is a background daemon that auto-analyzes as you type like they do when you’re editing in VSCode to hide that latency. That’s a pretty standard technique to solve this problem (typically LSC although I don’t know how VSCode does TypeScript)
    - duped 3y ago
      I was almost 100% certain that the typescript language support in VSCode was using the typescript language service library that's also used by tsc.
      - vlovich123 3y ago
        Sure but the command line version as best I can tell doesn’t bother keeping a long-lived tsc around. Sure, you can run it in watch mode but if you just run it it doesn’t bother doing that. For example, Facebook launches watchman to keep track of file modifications to files and keeps Buck’s dependency graph up to date so that Buck knows which targets are out of date instantly when you run the command. A more advanced version would know which targets you rebuild/run when you make a change like that and automatically refresh them. Same for running the tests.
roqi 3y ago
Is there any effort to get browsers to support typescript? Transpiling is great, but all the tooling required by a typescript project, from transpiling to barreling, is becoming daunting.
- Cthulhu_ 3y ago
  Deno is a nice project for running TS without a separate transpile process, but that's server-side only. Browser-side, they tried to add support for a second language via Dart, but that didn't work out.
- mcluck 3y ago
  You're mixing a couple of ideas. There is a proposal[1] to allow for type annotations in the browser but it's only a subset of what's possible in TS. As for barreling/bundling, that's never been a goal for TypeScript. That's handled by tools like Webpack and ESBuild. In fact, there's an effort going the opposite direction. As browsers support ES style modules, we don't need to bundle anymore as the browser will load the relevant files as needed [1] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
  - jeroenhd 3y ago
    I like the idea of JS modules but they don't entirely negate the need for bundling. Sending a single compressed, tree shaken, minified JS file down the pipe can be a lot more efficient than waiting for the browser to load all those files. Theoretically HTTP/2 push could've helped here, forcing the necessary files into the browser cache, but that's been removed from browsers.
    - mcluck 3y ago
      Agreed. To me, browser support for modules is great for debugging but is not a suitable replacement for producing an optimized set of bundles
- 3y ago
brundolf 3y ago
Extremely cool. It's crazy to think that the team built such an advanced tool for themselves, which very few other JS codebases can even benefit from. But the results speak for themselves, it was clearly worthwhile

111 points by aabbcc1241 3y ago

This is really impressive work, which can benefit other large JS tools. I realise this is sort of a dead horse, but rewriting the Typescript checker in Rust would not be an impossible task for a team as well-resourced as Microsoft’s. I know, because I rewrote a different 100KLOC typechecker myself in Rust (making a few small adjustments for a slightly different target language). It took me about a year. It would speed up the TypeScript typechecker at least 3-5x, which would save a lot of programmer time (and also datacenter energy consumption). There’s one obvious downside — it raises the bar for outside contributions — but given the expertise necessary to contribute usefully to a static analysis tool in the first place, and to contribute to TypeScript in particular, I’m not sure it’s a big additional impediment.

josteink 3y ago
A benefit of the typescript compiler being written in typescript is that the compiler-makers get to dogfood their own language. Rewriting it in rust would remove that important aspect c
- AntonCTO 3y ago
  Rust alone wouldn't help. TypeScript is very hard to compile and to understand because of its complexity. I think there is a need for a different architectural approach with huge parallelization. Some (CI) servers have plenty of cores. Heck, my laptop has 20 threads.
  - wffurr 3y ago
    swc and tsx are already significantly faster than tsc, partly due to being written in faster languages, or languages that make it easier to write fast code with minimal runtimes.
    - AntonCTO 3y ago
      Do they check types? Sorry, my previous comment wasn't very clear. Of course, faster languages produce faster results. But the language alone isn't enough in this case.
    - explaininjs 3y ago
      Neither of those check types. It’s easy to be fast when all you’re doing is filtering out type-bytes (and perhaps some transpiling). That’s nothing compared to actually type checking, which requires solving complex satisfiability problems across the entire codebase.
      - muglug 3y ago
        My understanding was that TypeScript would be more parellisable than Flow, which itself is plenty parallelisable: https://arxiv.org/pdf/1708.08021.pdf https://arxiv.org/pdf/1708.08021.pdf
        explaininjs 3y ago
        Call me crazy, but I prefer single threaded. It limits the potential impact on the rest of the system, and all cloud payment is by the core•hour anyways.
  - muglug 3y ago
    The approach is simple (I've implemented it, and so have many others): It takes three steps. Steps 1 and 3 are parellisable, and 2 should be very quick: 1. Convert every file in the repository to an AST, and perform static reflection on that AST. 2. Calcuate the inheritance graph for all the functions, classes etc. you've collected 3. Analyse every file, using the pre-calculated list of functions and classes available in each case.
- muglug 3y ago
  Yeah, that helps them stay close to the community and prevents any air of superiority that can come from writing Rust. But, while I’m sure it was really important initially, there are now very many test cases and early-adopters to help prevent regressions. And they still have that large TypeScript codebase to test their new tool on — it wouldn’t vanish.
- wffurr 3y ago
  Doesn’t seem worth the lost performance for the millions of Typescript users.
  - HPsquared 3y ago
    May give an incentive to improve the performance
    - mort96 3y ago
      Which they'd have to do through rewriting it in a faster language.
latchkey 3y ago
> I know, because I rewrote a different 100KLOC typechecker myself in Rust (making a few small adjustments for a slightly different target language). It took me about a year. It sounds like you could easily have a nice consulting gig for Microsoft.
comex 3y ago
Note that there’s at least one TypeScript type checker being developed in Rust by a third party: https://github.com/dudykr/stc https://github.com/dudykr/stc

DanHulton 3y ago

This is... good news, but I still cannot fathom using the default Typescript compiler for regular development. Seriously, leave the type-checking to your IDE and CICD chain, and switch to using tsx (https://www.npmjs.com/package/tsx https://www.npmjs.com/package/tsx) or swc (https://swc.rs/ https://swc.rs/) and you will _immediately_ notice the difference in speed and productivity.

herpdyderp 3y ago
I wish there was also a much faster type checker!
- vlovich123 3y ago
  I have absolutely 0 problems with the type checking that VSCode does. Always feel snappy. By comparison, command line performance is absolute crap though. The missing piece I suspect is a background daemon that auto-analyzes as you type like they do when you’re editing in VSCode to hide that latency. That’s a pretty standard technique to solve this problem (typically LSC although I don’t know how VSCode does TypeScript)
  - duped 3y ago
    I was almost 100% certain that the typescript language support in VSCode was using the typescript language service library that's also used by tsc.
    - vlovich123 3y ago
      Sure but the command line version as best I can tell doesn’t bother keeping a long-lived tsc around. Sure, you can run it in watch mode but if you just run it it doesn’t bother doing that. For example, Facebook launches watchman to keep track of file modifications to files and keeps Buck’s dependency graph up to date so that Buck knows which targets are out of date instantly when you run the command. A more advanced version would know which targets you rebuild/run when you make a change like that and automatically refresh them. Same for running the tests.

roqi 3y ago

Is there any effort to get browsers to support typescript? Transpiling is great, but all the tooling required by a typescript project, from transpiling to barreling, is becoming daunting.

Cthulhu_ 3y ago
Deno is a nice project for running TS without a separate transpile process, but that's server-side only. Browser-side, they tried to add support for a second language via Dart, but that didn't work out.
mcluck 3y ago
You're mixing a couple of ideas. There is a proposal[1] to allow for type annotations in the browser but it's only a subset of what's possible in TS. As for barreling/bundling, that's never been a goal for TypeScript. That's handled by tools like Webpack and ESBuild. In fact, there's an effort going the opposite direction. As browsers support ES style modules, we don't need to bundle anymore as the browser will load the relevant files as needed [1] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
- jeroenhd 3y ago
  I like the idea of JS modules but they don't entirely negate the need for bundling. Sending a single compressed, tree shaken, minified JS file down the pipe can be a lot more efficient than waiting for the browser to load all those files. Theoretically HTTP/2 push could've helped here, forcing the necessary files into the browser cache, but that's been removed from browsers.
  - mcluck 3y ago
    Agreed. To me, browser support for modules is great for debugging but is not a suitable replacement for producing an optimized set of bundles
3y ago

brundolf 3y ago

Extremely cool. It's crazy to think that the team built such an advanced tool for themselves, which very few other JS codebases can even benefit from. But the results speak for themselves, it was clearly worthwhile