Tuesday, June 12th, 2007

SlickSpeed CSS Selector TestSuite

Category: CSS, JavaScript, Library, MooTools

SlickSpeed is a CSS selector test suite provided by the MooTools folk.

This tool comes at the same time as they release CSS3 support in Mootools, and it compares Prototype, jQuery, MooTools, Ext, and CSS Query.

Every framework runs in his own iFrame, thus no conflicts can happen. Tests are run selector by selector, with an interval to prevent the browser from freeezing.

Tests are run in a neutral environment, no library or framework is included in the main javascript test, to avoid favoritism.

SpeedSlick

Posted by Dion Almaer at 8:10 am
32 Comments

++++-
4.5 rating from 97 votes

32 Comments »

Comments feed TrackBack URI

This is great! I’ve been waiting for a test like this :)
In FF2, prototype 1.5.1 and MooTools 1.2dev are reoughly 4 times as fast as ext 1.1b1. In IE7, ext 1.1b1 is fastest, although it’s even a bit slower than in FF. Interesting…

Comment by Kevinin — June 12, 2007

Very cool. You cannot go by the time at the bottom because the tests that error’ed out gave a responce of 0ms which scews the results.

Comment by very nice! — June 12, 2007

It would be nice if it was possible to download this tester to run it on a local server. So one could for example upgrade to newer versions or add other libraries to the list and run the benchmark again.

Comment by Spocke — June 12, 2007

When running IE7 and Safari3 Beta, Safari is much faster (> 5x).

S3: Fastest Prototype (68ms), Slowest CCSQuery (778ms)
IE7: Fastest Ext (479ms), Slowest CSSQuery (4240ms)

Comment by Stephan Schmidt — June 12, 2007

Spocke: http://slickspeed.googlecode.com/svn/trunk/

Comment by digitarald — June 12, 2007

Very interesting… what surprises me is that these selectors return different amounts of matches across browsers. The number for the * selector changes between FF and IE6/7.

Also it seems that both prototype and mootools are both heavily optimized for FF while Ext is the best performer on IE6/7.

Comment by Jaap3 — June 12, 2007

Where’s dojo.query()?

Comment by Patrick Fitzgerald — June 12, 2007

Is there a big in CSSQuery when using a div ~ div selector? Because it came back with a result of 4843 ms | 4941 found

Comment by Yansky — June 12, 2007

Sorry my previous comment should read: “Is there a bug…” :)

Comment by Yansky — June 12, 2007

@Yanky – yes there is a bug in cssQuery for ~ selectors.

Comment by Dean Edwards — June 12, 2007

Yes–where is dojo.query in this? 0.9 nightlies should be easy to try this with…

Comment by Tom Trenka — June 12, 2007

Firefox 2.0 in Wine is slightly faster than native FF2 ;) And another funny thing: in Virtualbox things wasn’t that slow, Mootools even finished faster than on native i386 Ubuntu Linux.

Comment by DeadCabbit — June 12, 2007

all progressive humanity is waiting for Dojo 0.9 to be added to this test suite :)

Comment by Anton Kudris — June 12, 2007

maybe when Dojo 0.9 is officially released they will add it.. wait.

Comment by duh — June 12, 2007

Nice tests, though for the sake of a few milliseconds I know my clients thank me more for rapid development than any nerdy metrics! After various experiments I chose jQuery for its stunning ease of development, reliability and community support.

Comment by George — June 12, 2007

Nice. However I’m also chiming in, where is Dojo .9 ?

Comment by Vance Dubberly — June 12, 2007

Nice, on my machine (win xp pro) opera kicked ass, firefox really slow and safari (beta) not far behind opera.

I got errors with cssQuery in IE7

Comment by Dougal Matthews — June 12, 2007

Dojo 0.9M2 is now included in the tests.

the whole thing can also be downloaded from http://slickspeed.googlecode.com/svn/trunk/

Comment by Tom Occhino — June 12, 2007

The first time I ran it, it showed MooTools as the clear winner with PT in second followed by Ext. Now it shows PT as the winner with MooTools in second. I run it again and it shows Moo & PT tied for first followed by Dojo query.

In IE 7, I see Ext, then Dojo Query, then Moo.

Why the odd results?

Comment by Rey Bango — June 12, 2007

It looks like jQuery is not optimized for “div ~ div” slector which is taking half of the total execution time…

Comment by kangax — June 12, 2007

AVG calls out this page as having a Trojan. Careful kids

Comment by Marc Brooks — June 13, 2007

@Rey Bango – a lot of this has to do with your computer configuration, what your current cpu / mem usage is like, what browser youre using, etc. The biggest things to look for in the tests is accuracy and comparison of the number of matches to compared to the others. Speed is important yes, but when you are down in the 10s of milliseconds range, the differences are truly trivial.

@Marc Brooks – i assure you there is no Trojan on that page… you should probably look more deeply into the source of your problem and maybe consider some new antivirus software before telling the ‘kids’ to be careful. ;)

Comment by Tom Occhino — June 13, 2007

@Tom. I also get a AVG warning when Internet Explorer goes to the page and I assume this is why cssQuery is not working. All the other browsers are fine.

Oh wait…
Funnily enough its not giving me the same message today. However, I did get it yesterday.

Comment by Dougal Matthews — June 13, 2007

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fmootools.net%2Fslickspeed
http://validator.w3.org/check?uri=http%3A%2F%2Fmootools.net%2Fslickspeed

Running tests on non-validated pages?

Comment by Dougal Matthews — June 13, 2007

SAFARI beta on XP is damn fast on this test!

Comment by JSerror — June 13, 2007

@Dougal Matthews – who cares.

Comment by whocares — June 13, 2007

Dougal Matthews: You don’t see that the tests actually run on other pages inside the iframes? …

Comment by AMíPlin — June 13, 2007

Thanks for developing the test suite Valerio. The jQuery team will definitely be working on improving the selector performance after v1.1.3 is officially released. The test suite is very well designed and will certainly help us in optimizing the code.

I’m not quite sure that we’ll look at this as some type of battle, as mentioned in your blog post, but anything that helps us improve the jQuery library and project is certainly welcome. Thanks again for the test suite.

Comment by Rey Bango — June 13, 2007

So 1.1.3 will have the same speed issues as shown here? Is there no quick-fix, is this really such a big clean-up for the jQuery code? I looked at it and tried to find a way to make it better (i’m not a jquery user, just love JavaScript) … its really hard to read the code and sure hard to maintain, wish you good luck to make that faster.

Comment by AMíPlin — June 14, 2007

@AMíPlin: Its not so much a matter of clean up as it is about maintaining a small file size. To optimize it further, including adding XPath support, would mean increasing the file size and we’re careful about increasing the size of the jQuery lib. Our users appreciate the sub-20k library size. We’re considering alternatives though. Thanks for looking into improvements.

Comment by Rey Bango — June 14, 2007

AVG’s signature update from 6/14 has been updated to no longer call out the cssQuery-p.js file (packed version) as a trojan.

Comment by Marc Brooks — June 14, 2007

Just to let you know: running the testsuite (on a WinXPsp2 PC) for MooTools 993, Prototype 1.6rc0 and jQuery 1.21, I got the following results:

Firefox 2.0.0.7: MT: 239; P: 224; jQ: 757

Opera 9.22: MT: 108; P: 88; jQ: 259

Safari Beta 3.0.2: MT: 175; P: 96; jQ: 263

IE6sp1: no tests performed–crashed systematically on page loading :-(

Comment by Lisandro — October 3, 2007

Leave a comment

You must be logged in to post a comment.