Extreme JavaScript Performance • Hacker News Board

Re: Extreme JavaScript Performance

#11

Post by tumult » Sun, Nov 08, 2009, 8:05 PM UTC

jjs wrote: post #9

tumult wrote: post #7

Earlier quoted context omitted.

It has to do with JavaScript's "scope chain" method of looking up symbol bindings. If something isn't in the current scope, it has to incrementally check each "scope" (such a bastardization..) for the binding it's looking for. If it works its way back up to the global (window) object's "scope" and doesn't find it, it gives up and returns undefined. "with", try/catch, etc. all introduce another level of scope, which m…

Why can't scope be resolved at compile-time? I realize that things like window.x can be added at runtime, but local scopes ought to be simple to rule out.... as long as there are no calls to eval() ..... eval(), which can introduce local bindings at runtime from arbitrary, runtime-constructed strings .... Ugh. And since aliases to eval can also be created, in any scope, from other dynamically eval()'d code strings, y…

If you don't use eval, with, and a couple of other things, V8 and most of the other good engines will actually optimize that scope level somewhat. Introducing eval, with, etc will make that scope level and any more therein to be much more dynamic/slow.

Re: Extreme JavaScript Performance

#12

Post by kwamenum86 » Sun, Nov 08, 2009, 9:27 PM UTC

xilun wrote: post #10

Stupid microoptimisations. Not only one should never optimize prematurely, and that is noted in the slides, but one should also never optimize like that (at least in the JS context). The interpreters/compilers/whatever will evolve for the readable cases, not for obscure idiocies, and programs using these techniques today will just run slower tomorrow.

On a large Javascript codebase these optimizations actually make a difference. It could take SECONDS off your page load time, which is huge.

Re: Extreme JavaScript Performance

#13

Post by Tichy » Sun, Nov 08, 2009, 9:32 PM UTC

Didn't even know about the function.toString() method, but it seems to that actually the non-firefox implementations deserve the wtf. (javascript:(function(){return 2*3;}).toString() => function(){return 6;}). Can't an interpreter optimize anymore?

Re: Extreme JavaScript Performance

#14

Post by Tichy » Sun, Nov 08, 2009, 9:34 PM UTC

jjs wrote: post #9

tumult wrote: post #7

Earlier quoted context omitted.

It has to do with JavaScript's "scope chain" method of looking up symbol bindings. If something isn't in the current scope, it has to incrementally check each "scope" (such a bastardization..) for the binding it's looking for. If it works its way back up to the global (window) object's "scope" and doesn't find it, it gives up and returns undefined. "with", try/catch, etc. all introduce another level of scope, which m…

Why can't scope be resolved at compile-time? I realize that things like window.x can be added at runtime, but local scopes ought to be simple to rule out.... as long as there are no calls to eval() ..... eval(), which can introduce local bindings at runtime from arbitrary, runtime-constructed strings .... Ugh. And since aliases to eval can also be created, in any scope, from other dynamically eval()'d code strings, y…

"local scopes ought to be simple to rule out"

If it's easy to do, it is probably only a matter of time until the major implementations include it. They seem to be competing on speed, after all.

Re: Extreme JavaScript Performance

#15

Post by taitems » Sun, Nov 08, 2009, 11:57 PM UTC

The one I wish they had measured was createElement compared to innerHTML replacement.

In my job I was always shocked to see massive HTML strings appended or replaced in an objects innerHTML, and instead wrote lots of createElements and createTextNodes. Apparently, for performance's sake (and especially in loops) it is MUCH more efficient to use a string and replace methods to alter the content.

Re: Extreme JavaScript Performance

#16

Post by puffythefish » Mon, Nov 09, 2009, 1:06 AM UTC

These would be useful in something like the Closure Compiler http://code.google.com/closure/compiler/. Most seem like too much of a micro-optimization to use in real code though (especially given that they may change over time).

Re: Extreme JavaScript Performance

#17

Post by gurraman » Mon, Nov 09, 2009, 7:08 AM UTC

taitems wrote: post #15

The one I wish they had measured was createElement compared to innerHTML replacement. In my job I was always shocked to see massive HTML strings appended or replaced in an objects innerHTML, and instead wrote lots of createElements and createTextNodes. Apparently, for performance's sake (and especially in loops) it is MUCH more efficient to use a string and replace methods to alter the content.

Re: Extreme JavaScript Performance

#18

Post by loup-vaillant » Mon, Nov 09, 2009, 9:23 AM UTC

jws wrote: post #3

I wish his summary charts were less binary. He shades the "winner" algorithm's box green. But many of those wins are insignificant. I don't think I'd inflict ~~(1*"12.5") on someone for an insignificant gain when a parseInt() is obvious. (I also suspect that at least one of those implementations constant folded it.)

Maybe this was aimed as compiler writers (Google Closure), not the poor programmers?