Comments on: Prototype and Scriptaculous mini news

By: dperini

dperini — Sat, 31 Oct 2009 15:02:40 +0000

@Nosredna,
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:

http://www.fusejs.com/nwmatcher/match/

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.

By: Nosredna

Nosredna — Tue, 27 Oct 2009 18:32:08 +0000

@jdalton,

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.

By: jdalton

jdalton — Tue, 27 Oct 2009 17:04:58 +0000

@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.

By: Nosredna

Nosredna — Tue, 27 Oct 2009 14:38:35 +0000

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.

By: Nosredna

Nosredna — Tue, 27 Oct 2009 14:25:56 +0000

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

By: Kimoja

Kimoja — Tue, 27 Oct 2009 12:43:44 +0000

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

By: jdalton

jdalton — Mon, 26 Oct 2009 23:27:28 +0000

Also for those interested NWMatcher passes Prototype and jQuery unit tests
.
Prototype: http://bit.ly/XI6la
.
jQuery: http://bit.ly/34md5r
.
jQuery (edge): http://bit.ly/4rBhqh

By: Stakka

Stakka — Mon, 26 Oct 2009 22:32:13 +0000

@Kimoja
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.

By: jdalton

jdalton — Mon, 26 Oct 2009 19:12:50 +0000

For those interested the benchmarks for NWMatcher’s match() method, that Diego referenced, can be found here: http://bit.ly/elhgf

By: Kimoja

Kimoja — Mon, 26 Oct 2009 18:40:43 +0000

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 …

By: fabienmenager

fabienmenager — Mon, 26 Oct 2009 18:02:03 +0000

@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

By: jdalton

jdalton — Mon, 26 Oct 2009 17:48:12 +0000

@Kimoja Thanks for the continued comment spam http://dl.getdropbox.com/u/513327/idquery_fail.png (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.

By: Kimoja

Kimoja — Mon, 26 Oct 2009 17:27:33 +0000

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

http://code.google.com/p/idquery/downloads/list

or else

http://code.google.com/p/uupaa-js-spinoff/downloads/list

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 …

bye

By: dperini

dperini — Mon, 26 Oct 2009 16:42:33 +0000

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.

By: dperini

dperini — Mon, 26 Oct 2009 16:29:33 +0000

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 ?

By: Jadet

Jadet — Mon, 26 Oct 2009 16:18:50 +0000

@Stakka: That’s why it’s feature tested, have a look: http://github.com/dperini/nwmatcher/blob/master/src/nwmatcher.js#L122

By: Stakka

Stakka — Mon, 26 Oct 2009 16:13:19 +0000

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.

By: jdalton

jdalton — Mon, 26 Oct 2009 16:00:53 +0000

@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+.

By: Jadet

Jadet — Mon, 26 Oct 2009 15:57:14 +0000

@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.

By: Stakka

Stakka — Mon, 26 Oct 2009 14:57:39 +0000

@travisalmand
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.