CSS Selectors - Speed Myths

On of the things updated in Ext 1.1 RC1 was DomQuery, the CSS selector implementation in Ext. There seems to be a trend sweeping through all of the popular JavaScript libraries of implementing or improving existing DOM querying using CSS selectors. In fact, since my original post with querying benchmarks for the various selector implementations, overall selector processing power has gone from Pinto power to a Mustang GT 500.

Has it really?

While there is no doubt that there have been improvements in every library, the manner in which each has gotten there is different. Some use XPath support in FireFox to gain a slight edge in that browser, but lag way behind in other browsers. I have tried to remain as impartial as possible in my evaluations of each library’s implementation.

Mootools
The latest on the scene with their slickspeed post, has implemented a nice test suite. In fact, it was so easy to set up I decided to use it for the tests included in this post below.

For some reason, although their test suite is titled “speed/validity selectors test for frameworks”, it leaves out many useful selectors such as div.dialog.emphatic (multiple classes) and div:not(.dialog) but includes completely useless selectors such as div div div. I have added those two selectors in my tests below.

The Mootools selector implementation relies heavily on XPath in FireFox. Performance in other browsers drops significantly.

Prototype
Prototype’s selector implementation is based on the initial Ext DomQuery code mixed with XPath support in FireFox. I had high hopes when seeing the first benchmarks for their implementation, but somewhere something must have gone wrong. The XPath picks up a lot of slack in FireFox but similar to Mootools, performance in other browsers drops significantly.

Dojo
Dojo’s selector implementation borrows ideas from various sources. It also uses XPath in FireFox but it’s more selective in the selectors it converts to XPath. Its cross-browser performance is also pretty consistent.

jQuery
jQuery’s recent 1.1.3 release gave it quite a big boost in performance. jQuery, like Ext, does not use XPath in FireFox. Credit goes to John Resig for the most efficient nth-child implementation I have seen to date. In fact, Ext 1.1’s new nth-child implementation is modeled very closely after it.

jQuery was the only library other than Ext that passed all the tests.

Ext
DomQuery’s performance is based on highly optimized code. In FireFox, even without XPath Ext is right there in the mix - I think that says a lot about the efficiency of the code. DomQuery by far has the most consistent performance cross browser. Like jQuery, Ext supports unlimited chaining of filters and selectors and querying XML Documents.

Results

Here are my results. Bold indicates the fastest time.

IE7, FF2 and Opera 9 tested on Vista, Core 2 Duo 6600, 4GB RAM

Safari 2 tested on Mac OS X 10.4.9, Core 2 Duo T5600, 2GB RAM

IE6 tested on XP, Athlon x64 3200+, 1.5GB RAM

Run them yourself

http://extjs.com/playpen/slickspeed

Why another test?

These tests were conducted to test the 1.1 RC1 release, and to dispel some myths about the selector speed of each library.

This entry was posted on Tuesday, July 10th, 2007 at 9:19 am and is filed under Ext JS. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.