Re:TypeScript team released an explorer for performance tuning
by AntonCTO on Saturday May 13, 2023 @09:08AM
(#35928010)
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.
[ Parent
| on HN ]
Re:TypeScript team released an explorer for performance tuning
by wffurr on Saturday May 13, 2023 @09:51AM
(#35928385)
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.
Re:TypeScript team released an explorer for performance tuning
by AntonCTO on Saturday May 13, 2023 @09:56AM
(#35928422)
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.
Re:TypeScript team released an explorer for performance tuning
by explaininjs on Saturday May 13, 2023 @11:28AM
(#35929305)
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.
Re:TypeScript team released an explorer for performance tuning
by muglug on Saturday May 13, 2023 @04:19PM
(#35932298)
My understanding was that TypeScript would be more parellisable than Flow, which itself is plenty parallelisable: https://arxiv.org/pdf/1708.08021.pdf
Re:TypeScript team released an explorer for performance tuning
by explaininjs on Sunday May 14, 2023 @08:20PM
(#35942625)
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.
Re:TypeScript team released an explorer for performance tuning
by muglug on Saturday May 13, 2023 @04:03PM
(#35932170)
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.