Andreas Rossberg wrote:
Yes, VMs do a lot to handle these cases well, and e.g. produce a flat object representation for such examples. But like with all those optimisations they are just optimistic, you still need to guard all over the place, because JavaScript semantics is rather deprived of useful invariants. There is very little that provably holds for a larger region of code or for a non-trivial extend of object life time. So you get tons of repetitive checks even in optimised code.
That's one way to do it. Another is to invalidate more aggressively optimized, less-guarded code when the unlikely bad thing happens.
Classes won't improve performance because they don't introduce any new invariants either. They are just sugar.
Right, although the const class or "sealed class" idea is still on the ES7 agenda.
Struct types (see the binary data proposal) have far more potential on that front, as is already utilised in practice with typed arrays vs conventional JS arrays.
Indeed, this is where Emscripten with appropriate optimization on the target VM side is getting within 1.2x of native (and not done yet)
Like it or not, high-performance JavaScript will have to be far less dynamic and far more typed than what the language allows. ;)
You mean what current editions allow without resorting to typed arrays. What's stopping future editions from adding sealed classes, struct syntax, whatever it takes?
The final battle will be checked (real, not warning-only) type annotations. I'm not holding my breath after ES4, but who knows?
My point here is JS evolves. It's not always easy to extend, but the alternatives look much harder.
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
