Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Extreme JavaScript Performance

slideshare.net

Post reply on HN
Print view View original

1–10 of 18 posts

Re: Extreme JavaScript Performance

#3

Post by 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.)

Re: Extreme JavaScript Performance

#5

Post by 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
Or @ caching:

  $("a").each( function(){
    $(this).click(
      $(this).find("img").hide();
    );
  });

  // versus

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

Re: Extreme JavaScript Performance

#6

Post by _giu »

alecco wrote: post #4

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.

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.

Re: Extreme JavaScript Performance

#7

Post by tumult »

Scriptor wrote: post #2

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?

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.

Re: Extreme JavaScript Performance

#8

Post by alecco »

_giu wrote: post #6
alecco wrote: post #4

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.

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.

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

Re: Extreme JavaScript Performance

#9

Post by jjs »

tumult wrote: post #7
Scriptor wrote: post #2

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?

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

Re: Extreme JavaScript Performance

#10

Post by 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.
Post reply on HN