SlickSpeed updated

[Danillo Cesar]

Peppy new selector
http://jamesdonaghue.com/?p=40


http://jamesdonaghue.com/static/peppy/profile/slickspeed/
--
-----------------------------------------
Danillo César de O. Melo
www.sook.com.br

[Jan Kassens]

He cheats. He caches elements, even though he cant cache when the dom changes, so his results would have to be multiplied (slickspeed fires each query 4 times, iirc).

Btw. we will have a new Selector engine the next release (most likely).

-jan

/me doesnt like to compare the libraries by the selectors, all libraries are fast enough already, so selector speed should not make you're decision, but rather features and code style

--

my blog: http://blog.kassens.net

[Oskar Krawczyk]

I understand what you're saying Jan, however you need to see the thing
we're seeing – which is MooTools being on the fourth position in the
selector-speed race. And what we'd really like to see is MT being the
leader.

Personally, I'm really psyched to see the new selector engine in
action.

O.

[nwhite]

The selector speeds are trivial close to each other. The two that are substantially faster as Jan pointed out cheat.

The hang up on selector speeds are crazy. When is the last time you have made such heavy use of selectors? They come in handy but some of these tests I have never seen in real world use. Most of the selector rules can be optimized if you have even the slightest awareness of your document structure.

[Tom Occhino]

SlickSpeed...the gift and the curse...

[Jan Kassens]

Krawczyk, Sizzle doesn't cheat, but John Resig has done some great
stuff there, unfortunately all these tricks dont work in IE < 8.
Mainly he's doing caching, but IE has no event when the dom changed,
so caching doesnt work in ie, neither does the use of the
native .querySelectorAll which really boosts some selectors the newest
browsers.

MooTools' new selector engine will also make use of .querySelector and
probably caching (we need to make sure its worth, since you shouldnt
use the same query multiple times anyway).

jan

[Rey Bango]

Could not have said it better myself Tom. It was definitely a gift in
that it prompted everyone to speed up their selector engines but now,
I see it as detracting from focusing on more important development.
The selector engines across all of the major libs are amazingly fast
already.

Rey...

[davidwalsh83]

I agree with Bango. Is there really a difference between 2 and 5
milliseconds? They're all fast and what should be avoided is a
"pissing contest."

Great work Tom, Jan, and the rest of the team!

[JamesDonaghue]

Peppy doesn't cheat, it was a bug (in IE only) and it has been fixed
in the 0.1.2 release: http://jamesdonaghue.com/static/peppy/.

Also, if selector engines speeds aren't important then why even have a
tool like Slickspeed?
In fact why bother developing a selector engine at all if it is so
rarely used or is so unimportant?

The selector engines that exist are already fast, however it has been
shown that they can in fact be faster. I don't understand the
argument against this.
The importance of web applications is very great and anywhere that we
can achieve speed gains we should.

[Guillermo Rauch]

Peppy in my tests was noticeably faster than MooTools, jQuery and Dojo. Only rivaled by Sizzle followed by Ext. 

Nice work

--
Guillermo Rauch
http://devthought.com

[Iván N Paz]

I guess the slickspeed was truely useful in the begining and in
emerging frameworks... right now most frameworks are already highly
optimized and will rely mainly on the javascript engine of the
browsers (read V8, MonkeyWhatever..etc) to gain more speed.

In a 1000 elements query, what does 100ms really mean? Will you really
really need to select 1000 elements at once? ;-)

--
◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦
Ivanicus' Code Box
http://ivanicus.com/

[Jan Kassens]

Sorry James, if I was wrong. I guess I have to take a closer look at
your huge speed gains (nearly twice as fast in safari, the only
browser I tested). Anything special tricks you did there?

Jan

--
http://kassens.net

[nwhite]

James,

First off, nice work. I think it is important to have tests like slickspeed but its also important not to get caught up in the results. I  keep an eye on the the "orange" I really don't like the thought of different matches across different frameworks.

The biggest performance increase anyone can obtain is switching to a modern browser. Running these tests in IE6 & 7 runs multiple times slower regardless of the framework. With that said, Ext seems to be the fastest in IE.  YUI and Prototype are really hurting when running in IE.


The tests that slickspeed performs often differs from real world usage on several levels.

1.) Document size.
2.) The number of selections
3.) The lack of repetition of the same selector (minimizes the effectiveness of caching)
4.) Dom updates prevent some of the caching techniques as well.


Nathan