Comments on: JavaScript performance optimization, take 1

By: Amy

Amy — Mon, 19 Oct 2009 16:37:14 +0000

Hey Sho. So true about the wrapper functions and CSS selectors (and maybe some day, with wider support of getElementsByClassName, it won’t be).

Especially if you are doing a lot of super-interactive user interface, you might also want to be sure that not only do you not blow away/recreate the event handlers (as you describe above), but that you use capture and bubble effectively. Hopefully you’re already doing that :)

One other idea: tuning your traversals is great, but don’t underestimate the extra performance suck that extra elements can cause. The more extraneous elements you can strip out, the faster everything will be. Including CSS selectors.

You might try also looking thru the other items on this JavaScript performance checklist I put out today: http://slowjavascript.com/

Nota bene: I am the co-author of JavaScript Performance Rocks! (http://jsrocks.com/), a book specifically about this very topic. It’s long and very thorough, you might find it helpful. :)

By: keith

keith — Tue, 13 Oct 2009 16:11:40 +0000

Thanks for the clarification sho!

It’s funny: up until I read your article I’ve managed to completely neglect the fact that how the browsers handle CSS selectors may be completely different from how the popular JavaScript libraries handle them. This means that I need to start thinking more about having two different ways of optimizing CSS selectors: one for CSS statements (which are read right-to-left), and another strategy for optimizing the convenience selectors provided by jQuery, etc. Well.. guess it’s time to start digging around more in the jQuery code :)

By: sho

sho — Sat, 10 Oct 2009 16:00:43 +0000

Thanks for that info, Jay. Good to know.

By: Jay Freeman (saurik)

Jay Freeman (saurik) — Sat, 10 Oct 2009 12:11:30 +0000

In point of fact, Opera 9.5, Safari 3.1, Chrome, and Firefox 3 all provide native implementations of getElementsByClassName, as specified by HTML5. Hopefully your JS library is taking advantage of this, but given your performance figures I can only assume it isn’t. It is incredibly unfortunate how much worse the state of browser performance is due to popular libraries refusing to take advantage of browser-specific features, no matter how commonly implemented. For the record, I believe JQuery finally changed their policy on this matter, which may be another reason to switch to it.

By: sho

sho — Sat, 10 Oct 2009 02:33:53 +0000

Ah. I forgot to mention why I tried that.

The selectors module in mootools (and I imagine jquery) splits apart the selector into multiple parts and performs the fastest actions first.

If the selector contains an id, the element is recovered using the low level DOM method getElementById().

If the selector contains a tag, the list of candidate elements is computed using the low level DOM method getElementsByTagName().

If neither a tag nor an id are provided, the entire subtree must be searched.

For classes and pseudo elements, there is no low-level DOM call to find these, so each element must be checked one by one using JavaScript.

Adding the class to the selector thus helps speed things up by narrowing the list of tags to search through via a quick DOM call.

By: keith

keith — Sat, 10 Oct 2009 02:24:39 +0000

Thanks for the tips :) I’m a little suprised that selecting for div.class over .class would improve performance. I used to think that selectors worked left to right, and by being more specific, it would make it easier on the browser. There was an article by Steve Souders (http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/) not too long ago, however, which mentioned that selectors are matched from right to left though. Since that’s the case, wouldn’t it be quicker to just match .class instead of div.class?