Re:The TypeScript compiler is now implemented internally wit...
by RyanCavanaugh on Wednesday November 02, 2022 @03:25PM
(#33441578)
I don't see how this is a rebuttal to the claim. 636,975 is more than 2x 304,526, so assuming the quoted paragraph is correct, sucrase is still the highest-throughput transpiler even during its warm-up phase. Probably this isn't true for the first 100 milliseconds of execution during the very first warm-up stages, but if the transpile phase is that short, it's basically irrelevant anyway.
[ Parent
| on HN ]
Re:The TypeScript compiler is now implemented internally wit...
by merb on Wednesday November 02, 2022 @03:41PM
(#33441808)
the warm-up phase is the whole reason why esbuild and swc exists btw. and also the sample is basically a small hello world. any real project would do a little more and the jit would not optimize as much.
also 2x 300k is not really the way how multi-threading works... especially not golang, which should not be run with GOMAXPROCS=1
Re:The TypeScript compiler is now implemented internally wit...
by cxr on Wednesday November 02, 2022 @05:53PM
(#33443417)
As far as I can follow your argument, it seems to be that the native tools perform better on the small inputs (that only ever take a second or three to complete), and that the creators ("maintainers"?) of Sucrase have their thumb on the scale or something, since they emphasize in their results the very large inputs that will involve longer running jobs where their tool has had a chance to warm up. In other words, the tools you're defending only do better when it doesn't really matter, and the tool you're downplaying outperforms the competition on the jobs where it actually does matter. If anything is backwards (or "stupid", as you put it) then that seems to be it.
Maybe I'm misunderstanding. In that case, please provide a better benchmark.