3 ms·

This is a very good talk but I wonder if this alternate compiler design has actually made the TypeScript compiler slower in normal compilation mode. If you real

This is a very good talk but I wonder if this alternate compiler design has actually made the TypeScript compiler slower in normal compilation mode. If you really do "helicopter in" to every point in the syntax tree and run IDE queries to implement type checking then that could potentially be much slower if there's any overhead at all to doing that. I've been experimenting with programming languages and compilers myself (https://github.com/evanw/skew https://github.com/evanw/skew) and my compiler appears to be ~2x faster than tsc when run with node even though it's also doing constant folding, tree shaking, inlining, and minification while tsc is just removing type annotations (my compiler appears to be ~15x faster when run natively). The slow compilation speed of tsc is my main complaint about the TypeScript ecosystem.

nv-vn 10y ago
The compiler doesn't just remove the type annotation, it has to go through and check that the annotations are valid and that the type safety is kept throughout the program. Type checking is often not a quick process, since it requires every single value in the program to have its type verified. If I declare that a variable is an integer and set it to the result of the function, the compiler has to make sure that that function returns an integer and not some other type, or that the type that function returns can be implicitly converted to an integer. And for that to be safe, it has to first prove that the function being called can be given that type, etc.
- constexpr 10y ago
  I know what type checking is. :) Both Skew and TypeScript are type-checked languages. Just because a compiler does type checking doesn't mean it has to be a lot slower. I was just pointing out that it would be interesting if this alternate compiler design was the reason why the TypeScript compiler is so slow relative to another compiler for a similar language (object-oriented, typed, garbage collected, etc.) that also uses the node runtime, especially since that other compiler is doing even more work than tsc.
wwwigham 10y ago
If you run tsc with benchmarking on, you'll find that almost all the time is taken up by the typechecker. Increasingly, TypeScript is adding control-flow-analysis-based[1] and contextual type system features... Saying that it just 'removes' type annotations as a bit disingenuous, as processing the type constraints those annotations apply is one of the most time consuming tasks TS can perform! TypeScript is structural, too, so for every comparison it can need to get down to the nitty-gritty of comparing individual object members... Recursively. TS does heavy cacheing of not just types, but the relationships between types - just to avoid redoing any work, where possible. FYI, the 'helicoptering in' doesn't affect full-program compilation time because of the mentioned cacheing. Since the state of the world is unchanged during a build, the parsetree and type hierarchy are only built once. Additionally, you'd find that incremental builds (tsc --watch) are relatively snappy because of the heavy cacheing done and the tree reuse, and so has benefitted from the architecture improvements for service work. [1]https://github.com/Microsoft/TypeScript/pull/8010 https://github.com/Microsoft/TypeScript/pull/8010

nv-vn 10y ago

The compiler doesn't just remove the type annotation, it has to go through and check that the annotations are valid and that the type safety is kept throughout the program. Type checking is often not a quick process, since it requires every single value in the program to have its type verified. If I declare that a variable is an integer and set it to the result of the function, the compiler has to make sure that that function returns an integer and not some other type, or that the type that function returns can be implicitly converted to an integer. And for that to be safe, it has to first prove that the function being called can be given that type, etc.

constexpr 10y ago
I know what type checking is. :) Both Skew and TypeScript are type-checked languages. Just because a compiler does type checking doesn't mean it has to be a lot slower. I was just pointing out that it would be interesting if this alternate compiler design was the reason why the TypeScript compiler is so slow relative to another compiler for a similar language (object-oriented, typed, garbage collected, etc.) that also uses the node runtime, especially since that other compiler is doing even more work than tsc.

wwwigham 10y ago

If you run tsc with benchmarking on, you'll find that almost all the time is taken up by the typechecker. Increasingly, TypeScript is adding control-flow-analysis-based[1] and contextual type system features... Saying that it just 'removes' type annotations as a bit disingenuous, as processing the type constraints those annotations apply is one of the most time consuming tasks TS can perform! TypeScript is structural, too, so for every comparison it can need to get down to the nitty-gritty of comparing individual object members... Recursively. TS does heavy cacheing of not just types, but the relationships between types - just to avoid redoing any work, where possible. FYI, the 'helicoptering in' doesn't affect full-program compilation time because of the mentioned cacheing. Since the state of the world is unchanged during a build, the parsetree and type hierarchy are only built once. Additionally, you'd find that incremental builds (tsc --watch) are relatively snappy because of the heavy cacheing done and the tree reuse, and so has benefitted from the architecture improvements for service work. [1]https://github.com/Microsoft/TypeScript/pull/8010 https://github.com/Microsoft/TypeScript/pull/8010