Performance benefits of static typing

[NiedziolkaMichal]

I would like the performance benefits of static typing to be taken into consideration, while deciding the shape of this proposal. There is a very interesting talk of Tzvetan Mikov available under this address on youtube, which shows that JavaScript could be even 20x faster if types of variables and parameters are strict and known. It's possible that this compiler will work out very well and in a few years, we might be considering whether some parts of it could be implemented in V8/JSC/SpiderMonkey. We might want to declare primitive types on parameters & variables, just so JS engines can apply various optimizations before any code is executed and let those parts run significantly faster. This will no longer be possible if the current proposal passes, because by then, web will be filled with JS code contaning meaningless type annotations that are not verified at runtime.

[ljharb]

Most implementers, however, have implied this would be a very large performance hit.

[egasimus]

We might want to declare primitive types on parameters & variables, just so JS engines can apply various optimizations before any code is executed and let those parts run significantly faster. This will no longer be possible if the current proposal passes, because by then, web will be filled with JS code contaning meaningless type annotations that are not verified at runtime.

I'm not sure I understand how the conclusion follows from the premise here.

I read this as an implication that it's virtually impossible to design a type annotation syntax today so that it would be compatible with, and useful to, the optimizing compiler of tomorrow. But I fail to see why that would that be the case.

https://www.assemblyscript.org/ comes to mind as tangentially related: an example of adapting a pre-existing type syntax (TS-based) for a static compiler (to WASM, not native engine's IR, but still).

[egasimus]

Most implementers, however, have implied this would be a very large performance hit.

Also curious about why this would be the case. My naive intuition is that more type info available in the source = easier to make better optimizations. Any links to explanations why it would do the opposite? Is it just a matter of parsing type info outweighing massively the optimizations made possible by the presence of the type info, or is the current generation of optimizations somehow dependent on dynamic typing?

[dragomirtitian]

@egasimus

The talk is very interesting, but even the presenter concedes, this is not for your whole application. I also find it interesting that they only showed primitives. That is usually the simple part of validating types at runtime. How do you validate objects? Or array of objects?

If we want to keep a dynamic version of JS, where you can just create object literals, how do we validate those types when we pass them to functions that require a specific declared type (or even worse a specific memory layout for that object). We can think of different language with different constraints that would look like ES that could make this work, but it would not be ES anymore.

Either way, I don't think the current version of types as comments precludes something like static hermes from existing. They could benefit from adding their own type comments to augment what TS / Flow already do.

[NiedziolkaMichal]

I am guessing that performance hit could be coming from process of parsing object types(so interface, type & object notation) and verifying that they match the actual objects that are being used in runtime. For a very simple cases like let a: number = 5;, I think JS engines could get a performance boost, but I am just speculating based on what I have heard from the talk.

Now if that's the case, and declaring primitive types like number or even something more precise like int32 could bring very high performance benefits, I think it would be very much worth to add it to the language. The : syntax could be used to declare those sound types, for example:

function asd(a: number, b: int32): number {
   let c: int32 = 5;
   return a + b + c;
}

Now, if the current proposal passes and npm is already filled with lots of JS files in which types don't match what is declared(asd("555", 33)), we will not be able to introduce sound types with : syntax without breaking existing code(for example because "555" + 33 + 5 now returns 555335 and sound types would make it throw an exception).

[egasimus]

Now I see what you mean, thanks for elaborating!

[Jamesernator]

Most implementers, however, have implied this would be a very large performance hit.

A hit where? Like if it's just parsing, well this really suggests the problem is that the binary ast proposal should be revived.

For runtime types, obviously work would needed to be done to support it everywhere, but there's no obvious reason for performance losses except at the boundary between typed and untyped (but in a fully typed codebase, this boundary would often not exist anyway).