

Extreme JavaScript Performance - _giu
http://www.slideshare.net/madrobby/extreme-javascript-performance

======
jws
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.)

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

------
xilun
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.

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

------
puffythefish
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).

------
adatta02
I'd be more interested in seeing these techniques applied to Javascript that
is coded up with a framework (say jQuery for arguments sake).

For example, what is the performance penalty of:

    
    
      var arr = [1, 2, 3];
      for(var i=0; i < arr.length; i++){ //stuff }
      // versus
      $.each( arr, function(i, val){ // stuff } );
    

Or @ caching:

    
    
      $("a").each( function(){
        $(this).click(
          $(this).find("img").hide();
        );
      });
    
      // versus
    
      $("a").each( function(){
        var targetImage = $(this).find("img");
        $(this).click(
          $(targetImage).hide();
        );
      });

------
Tichy
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?

------
taitems
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.

~~~
gurraman
See also: createDocumentFragment()

<http://ejohn.org/blog/dom-documentfragments/>

------
alecco
Author's page with PDF of slides

<http://mir.aculo.us/> <http://script.aculo.us/downloads/extremejs.pdf>

Slideshare is terribly unresponsive at times, and the registration's capcha
doesn't work properly.

~~~
_giu
thanks for the alternative link and the hint regarding Slideshare. next time
when I find an interesting presentation on Slideshare I'll look out for an
alternative link.

~~~
alecco
Good find, BTW. I'm looking forward to Douglas Crockford's presentation on
JSconf.eu :)

------
Scriptor
How come JIT compilers seem to have a problem with compiling try/catch blocks?
Also, why does caching the window object increase performance by significant
margins in some of the browsers?

~~~
tumult
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 means
anything you reference that isn't in that scope directly takes more time to
look up. Yeah, it's pretty retarded.

~~~
jjs
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, you can't even be sure that _any_ nonlocal
symbol won't resolve to eval.

So the only way you can be sure that a level of scope can be skipped in the
lookup chain is if there are _no_ function calls made on any redefinable
nonlocal symbols.

If there were a subset of javascript where eval was a keyword instead of an
identifier, then this would be easier.

~~~
tumult
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.

