Comments on: jQuery 1.3 beta: Sizzling and feature testing

By: BenGerrissen

BenGerrissen — Fri, 26 Dec 2008 17:05:28 +0000

@kissmyawesome
My opinion towards IE6 is pretty pragmatic and I am very blunt towards clients about it. It’s silly to expect ferari performances from a lada, same goes for RIA in old and new browsers. ps. IE6 was the ferari of it’s time, never compare it with current browser, but compare it with contemporaries like NS4. Like the car industry, don’t dispair at progress because people still like to drive old timers.
.
As for memoizing, you can cache a lot more then just the end result. For queries there wont be much of a performance boost, you might even lose 1 or 2 ms of speed. But for event delegation, it becomes quite vital since it’s realistic to expect over 100 node-pattern comparison calls in 1-2 second(s), with complex patterns, this will bog down the computer. Not very web2.0.
.
For methods like :nth-child(2n+1) for example, some extra parsing is required to filter out the formula, you don’t want to do this every single time you try to match a node to a pattern. You can memoize the result easily and next time, it’s like calling cache[:nth-child(2n+1)] and you get the argument set you need right away.
.
None of the selector engines, are fit enough for web2.0 event delegation imo. until they start memoizing more.
.
I am working on another query/nodematching engine myself >.<, so I take great interest in the guts of these selector engines, though JR and JD are making me wanna quit my selector engine project =P

By: kissmyawesome

kissmyawesome — Thu, 25 Dec 2008 19:40:54 +0000

Am I sad enough to sneak on here on Christmas day? Seems like it!
.
@ eyelidlessness – I suppose what I meant to say was that a looking at a single list of selectors might not tell the whole story. I’d like to see a version of SlickSpeed that allows me to create a custom list and see the results (without having to download from googlecode etc).
.
@ BenGerrissen – speed will become less of an issue, but only until IE6 is truly on its way out. Also, could you explain what you mean by memoizing instead of caching? I understand the technique, just not how it could relate to node lookups.
.
@ DavidMark – hate to say it, but it is you who seems rather unfriendly. Sure there are lots of things to improve about jQuery but the same could be said for any JS library. Nothing’s perfect, and the whole point of this post is about improvements…

By: DavidMark

DavidMark — Thu, 25 Dec 2008 04:22:56 +0000

And nice commentator links on this page (http://null/). It seems the Ajaxians are not friendly.

By: DavidMark

DavidMark — Thu, 25 Dec 2008 04:14:49 +0000

John Resig is a false prophet and jQuery a superstition.

He’s been told repeatedly that his incessant browser sniffing was a sign of incompetence. So he finally figured it out.

Same for the sluggish queries.

None of this matters as the script is still hampered by design flaws that can’t be rectified without a total rewrite.

By: BenGerrissen

BenGerrissen — Wed, 24 Dec 2008 14:20:28 +0000

Peppy currently beats all other selector engines, including Sizzle.
Though looking through the code, Sizzle is currently best enginered and more failsafe. However, Peppy is a sure contender if James fixes a few issues.

With these benchmarks and the fact that browsers are implementing faster JS runtimes, speed becomes less and less of an issue. The next step is supporting missing selectors, creating a robuster pattern parser ( for example h1:contains( (((my pretty weird title))) ) breaks on most if not all selector engines.

All engines would also benefit immensly with memoizing instead of the caching they use now.

And for plugging in code into any js library, developers might consider the following pattern:

(function(ns){
ns.query = SelectorEngine;
}(myNameSpace);

Supports X without sacrificing speed becomes the next holy grail ^^

By: eyelidlessness

eyelidlessness — Tue, 23 Dec 2008 20:12:44 +0000

“its not that useful as an indication of how a certain library might actually perform in your web app.”

On the contrary, I suspect it reflects real-world usage in that respect. It’s highly unlikely that most apps are going to be breaking both the browser and library caches so as to give “fresh” results at every point.

By: diehardboss

diehardboss — Tue, 23 Dec 2008 17:26:57 +0000

I hate IE6, but I have to support it for enterprise web apps at work (testing with http://experiment.bcse.info/slickspeed/, cache is cleared from “Internet Options…”):

base2 1.0 620
dojo 1.2.2 1078
DOMAssistant 2.7.4 368
Ext JS 2.2 354
jQuery 1.2.6 602
jQuery 1.3b1 620
MooTools 1.2.1 924
peppy 0.1.2b 523
prototype 1.6.0.3 3631
Sizzle 0.9 601
YUI 2.6.0 2183
YUI 3.0.0pr2 2411

The most popular JS Library, prototype, is very disappointing and they been around a long time. I’m also disappointed with YUI coming from a big company.

It’s a good thing I am using jQuery.

By: bunyan

bunyan — Tue, 23 Dec 2008 13:07:08 +0000

Wow. No more livequery plugin…

By: kissmyawesome

kissmyawesome — Tue, 23 Dec 2008 11:45:37 +0000

I’m always suprised at how much faith is put in slickspeed. In an unaltered form, its results are wildly misleading due to the averaging of tests which, after the first run, are likely to be cached. Furthermore, the speed of some selectors will be based on which selectors have already been run; you can quite easily change the final score just by reordering the selector list.

I’m not saying its useless, just that its not that useful as an indication of how a certain library might actually perform in your web app.

Anyway, good to see jQuery coming on.

By: Aimos

Aimos — Tue, 23 Dec 2008 11:24:34 +0000

I checked my screenshots again, for some further conclusions:
.
Top 4, by browser:
IE7: Ext JS 2.2: 80ms, DOMA 2.7.4: 116ms, peppy 0.1.2b: 114ms, Sizzle: 172ms
FF3: peppy: 21ms, Sizzle: 23ms, base2: 70ms, Ext JS: 80ms
O9: peppy: 0ms!, Sizzle: 4ms, ExtJS and base2: 20ms, DOMA: 24ms
C1: peppy: 7ms, Sizzle: 8ms, jQuery 1.3b: 10ms, DOMA: 14ms
.
The difference between 80ms and 172ms or 21ms and 80ms is “huge” compared to 7ms and 14ms. I think there is still room for peeking here and there to optimize the own solution. I cannot belive, hence I did not checked the source, that every of these engines ignores the domhaschanged event, mentioned before by ejohn about the peppy engine.
.
@bsce: I though “different returned elements” means different from the expected. That kinda confuses me every time. I still don#t know which is right with the returned result. If selector engines live in democracy I’ll judge the majority as success and correct. :]

By: bcse

bcse — Tue, 23 Dec 2008 09:57:00 +0000

@Aimos: “different returned elements” means not all engine return the same result, not every engine are failed. One failed, then they’re different.

By: bcse

bcse — Tue, 23 Dec 2008 09:44:34 +0000

@Aimos: “base2″ is http://code.google.com/p/base2/

By: V1

V1 — Tue, 23 Dec 2008 09:43:49 +0000

fun to see that peppy is still the fastest..

By: Aimos

Aimos — Tue, 23 Dec 2008 09:34:50 +0000

With fail I mean “different returned elements” according to the slickspeed legend at the bottom. I think thats wrong is’nt it?

By: Aimos

Aimos — Tue, 23 Dec 2008 09:28:34 +0000

Thanks bcse, here my results for everyone. I did a quick test with 4 browsers: Opera 9.63, IE7, FF3 latest and Chrome 1.0.154.36. XP, all patches, german, fast Core2Duo E6600 or so PC.
.
Screenshots:
Chrome: http://img3.imagebanana.com/view/chxwirc1/slickspeedc1015436.png
FireFox3: http://img3.imagebanana.com/view/jrjxyj1s/slickspeedff3.png
IE7: http://img3.imagebanana.com/view/eaknlzfl/slickspeedie7.png
Opera: http://img3.imagebanana.com/view/q4kgz9m8/slickspeedo963.png
.
In Chrome, the new jQuery is 3x faster, in FF3 a little slower, in IE7 equal and in Opera slightly faster.
.
You can also see the “overhead” of jQuery compared to Sizzle.
.
IE7: Sizzle: 172ms, jQuery: 216ms
FF3: Sizzle: 23ms, jQuery: 128ms
O9: Sizzle: 4ms jQuery: 52ms
C1: Sizzle: 8ms, jQuery: 10ms (2ms “Overhead” yeah!!)
.
I don’t know what “base2″ is in that slickspeed, I never heard of in ajaxian or so. But I found it very strange that all selector engines seem to fail on div ~p, div[class|=dialog], p:contains(selector) and p:only-child. The guy how wrote slickspeed maybe should check if truely every browser in combination with every selector engine can fail on these 4 tasks. I connot belive this.

By: LeaVerou

LeaVerou — Tue, 23 Dec 2008 09:00:47 +0000

@bcse: Thanks for that.
Strange, in FF3 the old jQuery seems to be faster (according to SlickSpeed). O_o

By: bcse

bcse — Tue, 23 Dec 2008 02:07:41 +0000

@Aimos
Here you are.
http://experiment.bcse.info/slickspeed/

By: ramaboo

ramaboo — Mon, 22 Dec 2008 23:21:59 +0000

Woot… jQuery rocks! Time to start upgrading all my plugins.

By: kim3er

kim3er — Mon, 22 Dec 2008 20:41:50 +0000

Can’t wait to have a go.

By: Aimos

Aimos — Mon, 22 Dec 2008 20:36:25 +0000

Someone set up a slickspeed with jQ 1.3 beta please.