Re:V8 has optimized new JavaScript language features (2018)
by rewq4321 on Monday November 09, 2020 @04:42PM
(#25040314)
> There is no way to obscure the call to direct "eval" itself; the compiler knows clearly whether it occurs.
I must be misunderstanding you, because you've stated that very confidently.
window["e"+"val"](...)
Re:V8 has optimized new JavaScript language features (2018)
by syrrim on Saturday November 07, 2020 @06:12PM
(#25020689)
> There is no way to obscure the call to direct "eval" itself;
Jsfuck would like to have a word with you
Re:V8 has optimized new JavaScript language features (2018)
by jlokier on Saturday November 07, 2020 @08:48PM
(#25022008)
Nice try! The Jsfuck method can't encode a direct "eval", only an indirect one :-)
Thus the emphasis on direct. Well, Jsfuck can encode a direct eval inside an indirect eval, but that doesn't give it any advantages, it still can't access the surrounding lexical environment in the form of "let" and "const" variables.
(I didn't know about Jsfuck though - it looks fun, thanks!)
It's already known that functions containing direct "eval" are not subject to the same level of performance optimisations as other functions. There is no way to obscure the call to direct "eval" itself; the compiler knows clearly whether it occurs.
Without "eval" appearing syntactically inside a function's scope, there is no dynamic access to "let" variables, and there's no need for the JIT code to check the assumption at run time.
Despite no other assignments, the "let" variable does change value: It has the assigned value after the "let", and the "temporal dead zone" value before it in the same scope. However "const" also has this property so it's not obvious why there would be a speed difference.