3 ms·
I wouldn't be surprised if const and arrow functions actually make things slower. const, or at least a naive implementation of it, requires checking if the val
by venning 11y ago
I wouldn't be surprised if const and arrow functions actually make things slower. const, or at least a naive implementation of it, requires checking if the value is changed which var does not. Perhaps that could be equally performant in time.
Arrow functions seem like they would take (marginally) longer to parse than explicit function declarations due to having a more verbose AST that does not start with unambiguous tokens. That, and you have the implicit this binding which must come with a cost. Again, in time this might be okay.
- dangoor 11y agoWouldn't const be checked at compile time?
- venning 11y agoThat's still a check that var is not subject to. Hence, it's a little slower (in theory).
- phpnode 11y agoIn theory, the opposite, because a compiler knows that a constant binding never changes so the value it references can be inlined everywhere it is used without having to do runtime checks. But I think engines are not doing this yet.
- venning 11y agoI haven't written enough ES6 to answer this for myself, but doesn't the dynamic nature of the language mean that constants can be at risk of invalid LHS operations at run-time? (At least, those positioned high enough in the scope to be subject to the necessary operations, which could be a lot.) I'm thinking of eval specifically, but perhaps there are other ways of doing this.
- david-given 11y agoI think if you use eval, all bets are off anyway. But I think that in ES6 without eval you can't refer to the current scope in a dynamic way; which means that the engine can resolve bindings at compile time without worrying about people fiddling with scopes behind the scenes, which should simplify optimisation a lot.