Monday, October 26th, 2009

Prototype and Scriptaculous mini news

Category: Prototype, Scriptaculous

A couple of quick updates for the Protoscripty crowd:

Choose your own CSS selector adventure

Fancy changing your selector engine at will? Simply rake dist SELECTOR_ENGINE=nwmatcher to switch to NWMatcher and beyond.

What is the perf difference? Thanks to @jdalton you can give some tests a try! 1.8.3 is released

It aint as sexy as watching scripty2, but for those of us using 1.8.x for now, always nice to see an update. It is built for Prototype 1.6.1 and there are some other small changes and fixes too.

Posted by Dion Almaer at 12:48 am

3.9 rating from 69 votes


Comments feed TrackBack URI

This is awesome, great move! I wonder what’s the reasoning behind NWMatcher not being the default engine as it’s the fastest.

The majority doesn’t even care about what’s underneath or who wrote the engine. They don’t know what ‘new Function’ calls do, they just want what’s fastest. Putting speed above everything else promotes good selector engine competition. Especially with the option to change engine I think speed should have the highest priority.

Comment by Jadet — October 26, 2009

@Jadet: I think the Prototype team is working toward Caja compliance, which doesn’t allow eval or new Function. I haven’t looked at any benchmarks, but I’m guessing Sizzle has its strengths and NWMatcher has others, so which one is faster may depend on what kind of selectors you’re using.

Comment by smith — October 26, 2009

Caja makes sense, I’d argue that they have Caja compliance as those who actually care about it can now build Prototype with Sizzle. Benchmarks on the selectors people use most often could help to pick the right default selector engine.

Comment by Jadet — October 26, 2009

Well, in a previous discussion about NWMatcher on Ajaxian recently it was mentioned not to trust SlickSpeed but here we are again using SlickSpeed with NWMatcher.

In the tests I was commenting on, in pure ms there’s very little difference between NWMatcher and Sizzle. But the test shown here it uses ops/ms which shows NWMatcher with a huge lead.

Can someone explain to me why the difference between reporting ms in one SlickSpeed test and reporting ops/ms in another?

Comment by travisalmand — October 26, 2009

Some feel that ops/ms (operations per milisecond) offers better data then just ms (miliseconds per single operation).

Comment by BenGerrissen — October 26, 2009

@travisalmand: It’s more accurate and reliable to get the average of as many ops/sec then that of three operations (slickspeed’s default).

Comment by Jadet — October 26, 2009

The old version of Slickspeed didn’t give a true benchmark since it only ran the expression once. Timing in JavaScript is limited to milliseconds so this often yielded a 0 ms result. But that didn’t mean it was instant, just that it took less than 1 ms.

The new version of SlickSpeed executes the expression multiple time within a fixed amount of time and presents the number of iterations it managed to run during that time. This gives a much more accurate result.

NWMatcher caches the matching result nodes from each expression, unsafely relying on MutationEvents to evict from the cache. Thats why it seems so fast.

Comment by Stakka — October 26, 2009

@Stakka: NWMatcher feature tests Mutation Events and uses caching where available, this makes it safe. Caching works on most browsers, it doesn’t just seem fast.

Comment by Jadet — October 26, 2009

@Stakka you are mistaken, in the benchmarks dom-result caching is disabled via NW.Dom.setCache(false).
Also NWMatcher uses MutationEvents safely by not persisting them when they are not needed (avoiding the slow down side-effect you may be referring to). NWMatcher does not cache when using the .match() method and only caches results when using the select() method, when the browser supports mutation events, when it isnt using querySelectorAll for a given query, and the cache isn’t being initialized repeatedly (as in a while-loop). Dom result caching is one small part of what makes NWMatcher speedy and is not reflected in these tests.
The benchmarks in these tests are without dom-result caching, if caching were turned on you would see NWMatcher score jump up to 2000+.

Comment by jdalton — October 26, 2009

MutationEvent does not trigger when accessing attributes as properties, ie button.disabled = true instead of button.setAttributes(“disabled”,”disabled”) thats why i called it unsafe. This might not be a problem when using it with Prototype tho.

Comment by Stakka — October 26, 2009

@Stakka: That’s why it’s feature tested, have a look:

Comment by Jadet — October 26, 2009

The method under test in the ops/sec (thanks to JSLitmus) is the match() method. The match() method performs the basic operation of checking if an element matches a specific set of characteristics (the selector string).

The select() method performs a selection of elements from a given context, and filters them based on the same characteristics as above.

From the above it is clear that a select() method could be built from a series of match() operations on a set of elements.

Currently most libraries/frameworks use the reverse operation, they do a very expensive select() operation and check if the element matches one of the results. This is the high speed increase that can be seen in the ops/sec test.

Caching is not enabled/used on the match() method, there is nothing to cache as for the results themselves, they are just true/false values…

This will be very useful in a lot of places and boost performances and GUI responsiveness, first that comes to MY mind is obviously event delegation, look for new niceness in Prototype and libraries doing the same decision these great team made.

Having more options is good, isn’t it ?

Comment by dperini — October 26, 2009

Maybe it is lost in the long message above…
I am just talking about the JSLitmus test, not the Slickspeed one. “Slickspeed” is only testing the select() method that we all know and use already ;-)

And some addtion…

Looking at the latest Selectors API addition done recently, see webkitMatchesSelector() and mozMatchesSelector(), I hope you agree that the shift of thinking is coming to the browsers too. It is up to us understand how to make better use of these techniques.

NWMatcher will supplement these missing API/specifications for browser built from 2004 to 2009, I hope it does and I am here to patch it if it doesn’t. The technique is not unique and is already used in some already published libraries and some that are not yet ! Have fun.

Comment by dperini — October 26, 2009

Hi, if you want a really quick selector, it is here.

or else

In my tests NWMatcher is the slowest of framework, I do not understand why this excitement, besides, put in cache all results of parts of a rule, maybe faster, but consumes too much memory and eventually can slow the system. The library selector should especially concentrate on versions of IE that do not support querySelectorAll, but IE does not recognize MutationEvents …


Comment by Kimoja — October 26, 2009

@Kimoja Thanks for the continued comment spam (Firefox).
The result-cache is just a small part of NWMatcher and can be enabled/disabled via NW.Dom.setCache(false/true);
NWMatcher development is a continual process. I am sure the speed will be tweaked for IE in the near future.
NWMatcher ensures results are always returned as arrays, and promotes/advocates following spec by ensuring results in document order, respecting attribute case-sensitivity, and white-space as defined by spec. NWMatcher supports following standards over the speed race.

Comment by jdalton — October 26, 2009

@Kimoja, ARGH I saw an eval() ! I suggest you to revise your French too.

I didn’t know NWMatcher, but it looks really impressive and promising ! I’d really like it to become the default CSS selector of PrototypeJS

Comment by fabienmenager — October 26, 2009

I haven’t slickspeed version that you use, I use one that calculates the execution time of a request… and in my testing, I found a very different result from what you show me , on IE6, I’m 3 times faster than your library without cache, with, it’s almost 4 times faster… have you tested my source correctly (I provided with the bench)
If you could give me the source of your Slickspeed?

for the eval, I don’t understand what it ‘s the problem, I don’t use the building function, because the context is always window, but I could still do without …

Comment by Kimoja — October 26, 2009

For those interested the benchmarks for NWMatcher’s match() method, that Diego referenced, can be found here:

Comment by jdalton — October 26, 2009

The NWMatcher’s match() doesn’t selector nodes, it just match a given node against the expression, returning true/false. You’ll probably comparing it to a full querySelectorAll implementation.

Comment by Stakka — October 26, 2009

Also for those interested NWMatcher passes Prototype and jQuery unit tests
jQuery (edge):

Comment by jdalton — October 26, 2009

@ Stakka
I have made a comparison between the methods of selection …

Comment by Kimoja — October 27, 2009

Help me out here. Tell me some usage cases when I’d want a boolean to tell me if a selector matched.

Comment by Nosredna — October 27, 2009

NWMatcher is impressively fast in Chrome, but very disappointing compared to Sizzle in IE6 and IE7. Since IE6 and IE7 need the speed boost more than any other browsers, isn’t Sizzle the library mostly likely to make the biggest impact on the most users?

If you can get the IE speed to match Sizzle’s, you have a winner.

Comment by Nosredna — October 27, 2009

@Nosredna match() is used heavily in event delegation.
In my run the performance in IE6-yahoo-template for Prototype-NWMatcher work-in-progress (wip) was just 3 points behind P-Sizzle. NWMatcher is faster or equiv on common simple selectors like #id, .class, and tagName. Diego is aware of IE6/7 performance drag and has several things in the works to boost it.
Again, other engines are not following spec in many cases and this can cause inconsistencies between browsers. Following spec adds an extra performance hit. That said, NWMatcher still has a lot of room to improve and still has a few tricks up it’s sleeve to push performance further.
Thanks for the feedback.

Comment by jdalton — October 27, 2009


OK. I was going from an older version in a different SlickSpeed. If I get a chance I’ll test in some of my own code.

Comment by Nosredna — October 27, 2009

thanks for having a look at NWMatcher, I would like to point you to the match() test showing that performances boost are not just better against other engines but also better than browsers own native API implementations, see here:

the gains are quite big and the technique used is much better than what we have today, both Webkit and Firefox nightly includes the same methods and functionalities, they are not yet as fast but at least we can build benchmarks comparing with browsers native speeds.

Comment by dperini — October 31, 2009

Leave a comment

You must be logged in to post a comment.