jQuery vs. My Library

[David Mark]

Interesting. First I've heard of that. I just did a fairly involved
update, so perhaps I broke something. What platform. It appears to be
fine (if inexplicably slow) on Windows.

It runs fine in my copy of Opera 10.10 under Vista. Though I do get
these large responses for 'My Library' and 'My Library - QSA':

div + p 7576 µs 22 found
218 µs 22 found

div ~ p 7813 µs 183 found
308 µs 183 found

Those are definitely inefficient in the slowest lane (DOM traversal),
but I wouldn't expect Opera 10 to use that lane. Something odd is going
on there.

h1[id]:contains(Selectors) 147500 µs 1 found (both)

p:contains(selectors) 147500 µs 54 found (both)

p:nth-child(2n+1) 35714 µs 0 found
951 µs 166 found

pnly-child 27000 µs 3 found
201 µs 3 found

All of the child-related pseudo selectors are inefficient in the slowest
lane. And 2n+1 is not supported. That's the one that is crossed off my
SlickSpeed tests. I suppose I'd add it if requested.

Thanks Andrew. I'll have to download the latest Opera and see what (if
any) fuss is about. I know Opera 9.x is very fast and can't remember
which version of 10 I tested (or what the results were). I'll check again.

 

[David Mark]

I see. It was a new test page. I assume the error was in the page
itself and is now fixed. (?)

It runs fine in my copy of Opera 10.10 under Vista. Though I do get
these large responses for 'My Library' and 'My Library - QSA':

div + p 7576 µs 22 found
218 µs 22 found

div ~ p 7813 µs 183 found
308 µs 183 found

h1[id]:contains(Selectors) 147500 µs 1 found (both)

p:contains(selectors) 147500 µs 54 found (both)

p:nth-child(2n+1) 35714 µs 0 found
951 µs 166 found

pnly-child 27000 µs 3 found
201 µs 3 found

And I see this new test page uses _much_ higher numbers (and different
units). I thought I was seeing things before I read the rest of the
thread.

 

[David Mark]

I may be wrong about your motives or your expectations. But I am not
trying to convince anyone of something I don't believe to be true.

The version numbers were right there. Like I said, it was a
two-year-old page when you first found it.

I hadn't done anything to that page in
years until you started focusing on it. I don't even consider it a
particularly compelling test as running queries over and over is not
standard practice for an application. You misconstrued that my
comments about speed were strictly related to SlickSpeed.

I didn't start the focus on it. Your original message in this
discussion brought up the speed and suggested that people take your
speed test. Matt Kruse asked for your results, but you simply told
him to try it himself. That's when I added my own tests. This is
from [1]:

Here you go with the time-wasting. I told anyone who wanted to see some
empirical evidence to see the only page I had up at the time.

| Scott Sauyet wrote:
| >> Matt Kruse wrote:
| >>> David Mark wrote:
| >>>> And take a guess which is faster. Rather, don't guess but try
the the
| >>>> Speed Test.
| >>> Have you? Will you post the results?
| >> Huh? The Speed Test on my site. I've ran it in everything from
IE8 to
| >> FF1 (and most in between). My Library kills its contemporaries
(the
| >> further back you go, the larger the margin).
| > Are you referring to this?:
| > http://www.cinsoft.net/mylib-testspeed.html
|
| Yes.

At that time, the referenced page was a SlickSpeed test [2], although
it has since been changed to one that links to both SlickSpeed and
TaskSpeed tests.

Yes, I know. I did it.

Please remember what I've said in this discussion: My Library performs
very well, and is among the faster ones in many of the tests I've
seen.

Yes, I think that is self-evident. Thank you for your honesty in that.

But you've significantly oversold its speed in your original
and subsequent posts.

Not according to my testing, results of which I posted in droves when I
had the chance. I test a much wider variety of environments that...
well, anybody. And I post the results as I see fit (a lot lately).
What else do you want?

My Library is not the undisputed fastest
library for SlickSpeed.

It is as far as I can see. By far. But who cares? The TaskSpeed
results are more meaningful for reasons that should be obvious. Of
course, they have their problems too. The rules for the test functions
are just not clearly defined, so the individual renditions vary wildly.

That's all I've said, but I've given
significant backup to my words by posting up-to-date tests others can
run in their own environments.

Great. And I look forward to seeing the results from your version of
SlickSpeed, but I will want to see the new code first as it appears it
has been a subject of debate here of late.

 

[David Mark]

Based on the SlickSpeed tests John-David Dalton recently demonstrated,
I've created my own new version of SlickSpeed. It uses essentially
the same timer-loop method as he did, but then calculates and reports
the time per iteration in microseconds, totaling them in milliseconds
so that the final report looks more like the original one: smaller is
better again! I've chosen to run the test repeatedly until it's
taken over 250 ms, which seems to give a reasonably good balance
between accuracy and performance; the original 40 selectors take about
10 seconds per library tested.
Okay.


There is still one flaw that Richard Cornford pointed out [1]: the
loop also includes repeated calls to "new Date()". This will serve to
slow down all libraries and somewhat downplay the differences between
them. I'm considering ways to fix it, but for the moment it shouldn't
affect rankings, only the speed ratios between the libraries.

Makes sense. The difference is what matters.

My first pass at this is at:

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-02-12a/

I've tried it once so far (just now) in FF1 on XP Pro on a PC that is
over five years old.

2013.922 ms 4572.244 ms 3763.426 ms 1618.309 ms* 1431.766 ms*
1665.66 ms 75786.916 ms

I don't know what happened with YUI. But it was only one run. Too many
pink boxes (slowest) to think it will come out of it though. Prototype
didn't do too bad, but was disqualified for miscounting :contains
(unless they have stipulated that they do not support that selector).

I take issue with the inclusion of tests that are not supported by all
of the libraries. Doesn't make a lot of sense as not every library
claims to support the exact same set of selectors. For example, 2n and
2n + 1 are things I didn't feel like bothering with. I just can't see
getting that silly with this stuff. There are certainly many other CSS3
selectors that I do not (and will not) support for querying. If you
want more than what is supported, write an add-on (it's very easy to do
as the QSA addition illustrates).

There is a link in the footer to a zip file containing the PHP code
used.

My raw results are below, run against recent versions of the major
browsers on a powerful Windows XP machine.
Okay.

While this is still not a
home run for My Library, it's definitely getting to be a closer
contest on my developer's machine, at least with QSA.

With QSA it will always be a tight race, likely so tight that the
differences are unimportant. It's when the library has to "thunk" back
to DOM traversal that the difference vary widely. And that's important
as most browsers in use today do not support QSA at all (and those that
do do it less than perfectly).

While I
understand and partially agree with John-David's objections to the
current My Library QSA code [2], I think it's good enough for this
sort of testing at the moment, and I doubt the fixes to it will change
much in the way of speed.

I think a lot of the "fixes" would simply be adding support for
selectors that I don't deem worthy of support. Not all, of course, he
did notice some valid peculiarities and some of them have been fixed in
the interim.

The big news is that in these tests, in all browsers, except IE6 and
IE8 in compatibility mode, My Library (QSA) was the fastest for a
majority of the selectors.

I'm not surprised. Nor am I surprised that broken MSHTML
implementations are the exceptions. Those are where the wheels fall off
for every one of the others. Put a few choice attribute-related rules
in and they will predictably break down and veer off the course. And
these are obviously selectors they assert to support (and have asserted
so for some time). That's not good, especially when Web developers are
now being conditioned to "forget" IE < 8 (and as we know, IE8
compatibility mode is roughly equivalent to IE7).

But in none was it the overall fastest. JQuery was the fastest in
everything but IE6, where it came in third behind Dojo and MooTools.
In many browsers, if two of the selectors were optimized to match the
speed of the competition, My Library (QSA) would have been about the
fastest overall library. Those were the two selectors with
":contains": "h1[id]:contains(Selectors)" and
"p:contains(selectors)". In the various IE's there was a different
issue, "p:nth-child(even/odd)" were wrong in both versions of My
Library, and were significantly slower, too.

The even/odd discrepancy, which did not show up in my (obviously
incomplete) testing is a legitimate beef. Apparently I managed to make
those both slow and incorrect. It can happen. I'll grab your test page
as an example and fix it when I get a chance. Will also announce that
those two are broken in my forum. As far as I am concerned, the results
are disqualified until those two are fixed.

However, the inclusion of not:, 2n, 2n + 1 is misleading as I never
claimed to support those. That's why they are absent from my test page.
Well, the first was never there in the first place. I'm _not_ adding
that.

One other place where My Library might be able to do a little catch-up
is with some of the most commonly used selectors; jQuery is fastest,
and, in some environments, significantly faster than the competition,
at "tag" and "#id", which probably account for a large portion of the
selectors used in daily practice.

In my testing, it has been shown to be relatively fast at those sorts of
simple queries. The QSA version doesn't hand those off though (at least
not at the moment). I've been considering doing that in the QSA add-on.

The other point to make is that we've pretty much hit the point where
all the libraries are fast enough for most DOM tasks needed, and
especially for querying.

The most important thing to take out of all of this is to not use
queries for anything. It's the worst possible strategy, popular or not.

So although there will always be some
bragging rights over fastest speed, the raw speeds are likely to
become less and less relevant.

Like I've been saying, the TaskSpeed stuff is more compelling.

In any case, nice job, David!
Thanks!


(results below.)

-- Scott
____________________
[1] http://groups.google.com/group/comp.lang.javascript/msg/44cf1a85fe8075c0
[2] http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/7ee2e996c3fe952b

=================================================================
Resultss on Windows XP SP2 with dual 3.0 GHz CPUs, 3.25 GB RAM
=================================================================
dj = Dojo 1.4.0
jq = jQuery 1.4.1
mt = MooTools 1.2.4
ml = My Library, downloaded 2010-02-11
mlqsa = My Library with QuerySelectorAll, downloaded 2010-02-11
pr = Prototype 1.6.1
yui = Yahoo User Interface 3.0


Chrome 3.0.195.27:
------------------
dj:9 jq:6 mt:38 ml:61 mlqsa:12 pr:9 yui:12

Firefox 3.5.7:
--------------
dj:24 jq:16 mt:45 ml:94 mlqsa:22 pr:32 yui:20

IE6:
----
dj:871 jq:1295 mt:1004 ml:4856 mlqsa:4815 pr:2665 yui:1731

IE8 compat:
-----------
dj:188 jq:294 mt:588 ml:2926 mlqsa:1691 pr:1952 yui:707

IE8:

And of course, I'll really have to review the test code before I can
comment on these as anything but a series of numbers.

 

[David Mark]

Based on the SlickSpeed tests John-David Dalton recently demonstrated,
I've created my own new version of SlickSpeed.

[...]

Also, I am not sure why you guys are using API.getEBCS over and over.
The extra dot operation is unnecessary. The whole reason the (not
recommended for GP use) $ is in there is for tests like these. The
extra dot operation on each call just clouds the issue as you would
normally use something like this:-

var getEBCS = API.getEBCS;

....at the start. The API is not made up of methods in the strict sense.
The API is simply a "namespace" object containing the supported
functions (which vary according to the environment). They are functions
that don't refer to - this - at all.

 

[David Mark]

Based on the SlickSpeed tests John-David Dalton recently demonstrated,
I've created my own new version of SlickSpeed. It uses essentially
the same timer-loop method as he did, but then calculates and reports
the time per iteration in microseconds, totaling them in milliseconds
so that the final report looks more like the original one: smaller is
better again! I've chosen to run the test repeatedly until it's
taken over 250 ms, which seems to give a reasonably good balance
between accuracy and performance; the original 40 selectors take about
10 seconds per library tested.
Okay.

There is still one flaw that Richard Cornford pointed out [1]: the
loop also includes repeated calls to "new Date()". This will serve to
slow down all libraries and somewhat downplay the differences between
them. I'm considering ways to fix it, but for the moment it shouldn't
affect rankings, only the speed ratios between the libraries.

Makes sense. The difference is what matters.

My first pass at this is at:

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-02-12a/

I've tried it once so far (just now) in FF1 on XP Pro on a PC that is
over five years old.

2013.922 ms 4572.244 ms 3763.426 ms 1618.309 ms* 1431.766 ms*
1665.66 ms 75786.916 ms

I don't know what happened with YUI. But it was only one run. Too many
pink boxes (slowest) to think it will come out of it though. Prototype
didn't do too bad, but was disqualified for miscounting :contains
(unless they have stipulated that they do not support that selector).

I take issue with the inclusion of tests that are not supported by all
of the libraries. Doesn't make a lot of sense as not every library
claims to support the exact same set of selectors. For example, 2n and
2n + 1 are things I didn't feel like bothering with. I just can't see
getting that silly with this stuff. There are certainly many other CSS3
selectors that I do not (and will not) support for querying. If you
want more than what is supported, write an add-on (it's very easy to do
as the QSA addition illustrates).

There is a link in the footer to a zip file containing the PHP code
used.

My raw results are below, run against recent versions of the major
browsers on a powerful Windows XP machine.
Okay.

While this is still not a
home run for My Library, it's definitely getting to be a closer
contest on my developer's machine, at least with QSA.

With QSA it will always be a tight race, likely so tight that the
differences are unimportant. It's when the library has to "thunk" back
to DOM traversal that the difference vary widely. And that's important
as most browsers in use today do not support QSA at all (and those that
do do it less than perfectly).

While I
understand and partially agree with John-David's objections to the
current My Library QSA code [2], I think it's good enough for this
sort of testing at the moment, and I doubt the fixes to it will change
much in the way of speed.

I think a lot of the "fixes" would simply be adding support for
selectors that I don't deem worthy of support. Not all, of course, he
did notice some valid peculiarities and some of them have been fixed in
the interim.

The big news is that in these tests, in all browsers, except IE6 and
IE8 in compatibility mode, My Library (QSA) was the fastest for a
majority of the selectors.

I'm not surprised. Nor am I surprised that broken MSHTML
implementations are the exceptions. Those are where the wheels fall off
for every one of the others. Put a few choice attribute-related rules
in and they will predictably break down and veer off the course. And
these are obviously selectors they assert to support (and have asserted
so for some time). That's not good, especially when Web developers are
now being conditioned to "forget" IE < 8 (and as we know, IE8
compatibility mode is roughly equivalent to IE7).

But in none was it the overall fastest. JQuery was the fastest in
everything but IE6, where it came in third behind Dojo and MooTools.
In many browsers, if two of the selectors were optimized to match the
speed of the competition, My Library (QSA) would have been about the
fastest overall library. Those were the two selectors with
":contains": "h1[id]:contains(Selectors)" and
"p:contains(selectors)". In the various IE's there was a different
issue, "p:nth-child(even/odd)" were wrong in both versions of My
Library, and were significantly slower, too.

The even/odd discrepancy, which did not show up in my (obviously
incomplete) testing is a legitimate beef. Apparently I managed to make
those both slow and incorrect. It can happen. I'll grab your test page
as an example and fix it when I get a chance. Will also announce that
those two are broken in my forum. As far as I am concerned, the results
are disqualified until those two are fixed.

However, the inclusion of not:, 2n, 2n + 1 is misleading as I never
claimed to support those. That's why they are absent from my test page.
Well, the first was never there in the first place. I'm _not_ adding
that.

LOL. It appears that those last two are the same as even and odd
respectively. I never bothered to look them up as I didn't plan to
support them. Wouldn't have guessed they were aliases, but then now
that I think about it...

Suffice to say those will be "supported" shortly. Quotes indicate I
have reproduced the "slow lane" issue with evens/odds using the test
document from Scott's site. I'll fix that shortly.

Thanks for bringing that to my attention. I still insist you remove the
not: test as I have no plans to support _that_.

 

[David Mark]

Based on the SlickSpeed tests John-David Dalton recently demonstrated,
I've created my own new version of SlickSpeed. It uses essentially
the same timer-loop method as he did, but then calculates and reports
the time per iteration in microseconds, totaling them in milliseconds
so that the final report looks more like the original one: smaller is
better again! I've chosen to run the test repeatedly until it's
taken over 250 ms, which seems to give a reasonably good balance
between accuracy and performance; the original 40 selectors take about
10 seconds per library tested. Okay.

There is still one flaw that Richard Cornford pointed out [1]: the
loop also includes repeated calls to "new Date()". This will serve to
slow down all libraries and somewhat downplay the differences between
them. I'm considering ways to fix it, but for the moment it shouldn't
affect rankings, only the speed ratios between the libraries.

Makes sense. The difference is what matters.

My first pass at this is at:

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-02-12a/

I've tried it once so far (just now) in FF1 on XP Pro on a PC that is
over five years old.

2013.922 ms 4572.244 ms 3763.426 ms 1618.309 ms* 1431.766 ms*
1665.66 ms 75786.916 ms

I don't know what happened with YUI. But it was only one run. Too many
pink boxes (slowest) to think it will come out of it though. Prototype
didn't do too bad, but was disqualified for miscounting :contains
(unless they have stipulated that they do not support that selector).

I take issue with the inclusion of tests that are not supported by all
of the libraries. Doesn't make a lot of sense as not every library
claims to support the exact same set of selectors. For example, 2n and
2n + 1 are things I didn't feel like bothering with. I just can't see
getting that silly with this stuff. There are certainly many other CSS3
selectors that I do not (and will not) support for querying. If you
want more than what is supported, write an add-on (it's very easy to do
as the QSA addition illustrates).

There is a link in the footer to a zip file containing the PHP code
used.

My raw results are below, run against recent versions of the major
browsers on a powerful Windows XP machine. Okay.

While this is still not a
home run for My Library, it's definitely getting to be a closer
contest on my developer's machine, at least with QSA.

With QSA it will always be a tight race, likely so tight that the
differences are unimportant. It's when the library has to "thunk" back
to DOM traversal that the difference vary widely. And that's important
as most browsers in use today do not support QSA at all (and those that
do do it less than perfectly).

While I
understand and partially agree with John-David's objections to the
current My Library QSA code [2], I think it's good enough for this
sort of testing at the moment, and I doubt the fixes to it will change
much in the way of speed.

I think a lot of the "fixes" would simply be adding support for
selectors that I don't deem worthy of support. Not all, of course, he
did notice some valid peculiarities and some of them have been fixed in
the interim.

The big news is that in these tests, in all browsers, except IE6 and
IE8 in compatibility mode, My Library (QSA) was the fastest for a
majority of the selectors.

I'm not surprised. Nor am I surprised that broken MSHTML
implementations are the exceptions. Those are where the wheels fall off
for every one of the others. Put a few choice attribute-related rules
in and they will predictably break down and veer off the course. And
these are obviously selectors they assert to support (and have asserted
so for some time). That's not good, especially when Web developers are
now being conditioned to "forget" IE < 8 (and as we know, IE8
compatibility mode is roughly equivalent to IE7).

But in none was it the overall fastest. JQuery was the fastest in
everything but IE6, where it came in third behind Dojo and MooTools.
In many browsers, if two of the selectors were optimized to match the
speed of the competition, My Library (QSA) would have been about the
fastest overall library. Those were the two selectors with
":contains": "h1[id]:contains(Selectors)" and
"p:contains(selectors)". In the various IE's there was a different
issue, "p:nth-child(even/odd)" were wrong in both versions of My
Library, and were significantly slower, too.

The even/odd discrepancy, which did not show up in my (obviously
incomplete) testing is a legitimate beef. Apparently I managed to make
those both slow and incorrect. It can happen. I'll grab your test page
as an example and fix it when I get a chance. Will also announce that
those two are broken in my forum. As far as I am concerned, the results
are disqualified until those two are fixed.

However, the inclusion of not:, 2n, 2n + 1 is misleading as I never
claimed to support those. That's why they are absent from my test page.
Well, the first was never there in the first place. I'm _not_ adding
that.

LOL. It appears that those last two are the same as even and odd
respectively. I never bothered to look them up as I didn't plan to
support them. Wouldn't have guessed they were aliases, but then now
that I think about it...

Suffice to say those will be "supported" shortly. Quotes indicate I
have reproduced the "slow lane" issue with evens/odds using the test
document from Scott's site. I'll fix that shortly.

Thanks for bringing that to my attention. I still insist you remove the
not: test as I have no plans to support _that_.

I fixed the two broken selectors (even/odd). It was an oversight that I
accounted for the "!" tagName (comment) in all but those two pseudos.
Will update the Downloads page and repository shortly.

The 2n and 2n+1 aliases are now working (at least superficially-they are
just aliases for even/odd). I guess I'll have to go ahead and
generalize them now. Doesn't appear to be much of a chore.

Good idea to put some comments in the test document. I imagine that
will settle some of the alien unit test issues as well.

 

[David Mark]

That must have been in the test page. Opera 10.10 works fine for me on XP.

152 76 239 266 247 48 436 36 79 60* 60*

That's on my SlickSpeed page. I'll test Scott's once he updates it with
the even/odd fix.

 

[David Mark]

That must have been in the test page. Opera 10.10 works fine for me on XP.

152 76 239 266 247 48 436 36 79 60* 60*

Oops. Just one of those sixties should be marked (the latter). On the
initial run, it looks like the other QSA-enabled browsers came up
slightly faster (and one tied).

 

[Ivan S]

Interesting.  First I've heard of that.  I just did a fairly involved
update, so perhaps I broke something.  What platform.  It appears to be
fine (if inexplicably slow) on Windows.

XP, but that's fixed now. There was some problem in Opera cache (I'm
not sure why have that happend, because I was first time on that page,
so there was no cache), I cleared it and now tests run for all
libraries.

There are no large responses for Mylib, except in "contains" selectors
(if I remember correctly, it's slow in most of browsers).

 

[Scott Sauyet]

I see.  It was a new test page.  I assume the error was in the page
itself and is now fixed. (?)

In a subsequent post [1], Ivan replies that it was an odd issue with
the Opera cache. That page has been static since I announced it here,
and I rather doubt that the URL is one that someone might stumble
across.

And I see this new test page uses _much_ higher numbers (and different
units).  I thought I was seeing things before I read the rest of the
thread.  

I'm wondering if I should put something right on the page to point out
the different units; I'd rather not change any more of the original
than is necessary, which is why the totals row is reported in
milliseconds even though the individual items are in microseconds.
But yes, those numbers can be jarring at first!

-- Scott
____________________
[1] http://groups.google.com/group/comp.lang.javascript/msg/2f57d5a5ca351709

 

[Scott Sauyet]

Scott Sauyet wrote:

Yes, I think that is self-evident.  Thank you for your honesty in that.

I think you'll find that I'm quite empirical about these things; I
really look for the evidence, which is what got me testing these
claims in the first place.

Not according to my testing, results of which I posted in droves when I
had the chance.  I test a much wider variety of environments that...
well, anybody.  And I post the results as I see fit (a lot lately).
What else do you want?

According to my tests, My Library is getting faster, but is not the
fastest (at least not yet!) in the environments I care about. I
honestly don't give a damn about FF1, as I don't build pages I expect
end users to visit with that browser. My apps are also not yet aimed
at smartphones, but I can see that coming, so it's at least a
legitimate concern. What I mostly care about are the browsers used by
my target audience. IE6,7, & 8, recent versions of FF, Chrome, and
Safari. And although I don't see it much in my logs, I can't resist
checking recent versions of Opera too out of an old loyalty to the
browser.

It is as far as I can see.  By far.  But who cares?  The TaskSpeed
results are more meaningful for reasons that should be obvious.  

Yes, and even the speed results are only one factor of many in
choosing a tool.

Of
course, they have their problems too.  The rules for the test functions
are just not clearly defined, so the individual renditions vary wildly.

My main issue with the TaskSpeed tests is that it becomes far too easy
for test-writers to optimize the code for the tests rather than to use
their libraries as intended. I'm not sure there's any way around
that, because, unlike with the SlickSpeed tests, it takes someone
well versed in the library to write the test code appropriately; and
those people are likely the ones most invested in having the library
perform well in competition.

Great.  And I look forward to seeing the results from your version of
SlickSpeed, but I will want to see the new code first as it appears it
has been a subject of debate here of late.

I'm not sure if I will put out another version or not. The only issue
I've seen under discussion is the one I raised about the extra work in
the test loop. It most certainly affects the absolute speeds, but
should slow down all libraries an equal amount.

-- Scott

 

[Scott Sauyet]

Scott Sauyet wrote:
I take issue with the inclusion of tests that are not supported by all
of the libraries.  Doesn't make a lot of sense as not every library
claims to support the exact same set of selectors.  For example, 2n and
2n + 1 are things I didn't feel like bothering with.  I just can't see
getting that silly with this stuff.  There are certainly many other CSS3
selectors that I do not (and will not) support for querying.  If you
want more than what is supported, write an add-on (it's very easy to do
as the QSA addition illustrates).

I would definitely prefer not to mess with the list of selectors,
unless it's to add some weighing scheme based upon real-world selector
usage. I didn't write the list; it's the one that was in the early
versions of SlickSpeed and has been copied into many other versions.
If you want to host an altered version, as I said:

Changing selectors is very easy. There is a text file in the
distribution -- "selectors.list" -- containing one selector per line.
(If you don't have a PHP host available, I'm willing to post a version
with the selectors you choose.) The mechanism to deal with
unavailable selectors is naive, perhaps, but does it's job well
enough: it simply highlights every row where the number of results
vary between libraries, and highlights any individual test that throws
an error. Intentionally or not, the appearance of SlickSpeed did help
coalesce the minimum set of selectors libraries tended to support.
That's a good thing for developers looking to use one or the other.

I'm not surprised.  Nor am I surprised that broken MSHTML
implementations are the exceptions.  Those are where the wheels fall off
for every one of the others.  Put a few choice attribute-related rules
in and they will predictably break down and veer off the course.  And
these are obviously selectors they assert to support (and have asserted
so for some time).  That's not good, especially when Web developers are
now being conditioned to "forget" IE < 8 (and as we know, IE8
compatibility mode is roughly equivalent to IE7).

Well this is a test of selector speed. I haven't seen the other
libraries having problems with the attribute-based selectors. I know
there are other significant errors with other parts of attribute
handling.

But in none was it the overall fastest.  JQuery was the fastest in
everything but IE6, where it came in third behind Dojo and MooTools.
In many browsers, if two of the selectors were optimized to match the
speed of the competition, My Library (QSA) would have been about the
fastest overall library.  Those were the two selectors with
":contains": "h1[id]:contains(Selectors)" and
"p:contains(selectors)".  In the various IE's there was a different
issue, "p:nth-child(even/odd)" were wrong in both versions of My
Library, and were significantly slower, too.

The even/odd discrepancy, which did not show up in my (obviously
incomplete) testing is a legitimate beef.  Apparently I managed to make
those both slow and incorrect.  It can happen.  I'll grab your test page
as an example and fix it when I get a chance.  Will also announce that
those two are broken in my forum.  As far as I am concerned, the results
are disqualified until those two are fixed.

That's an odd statement. The results still stand. They have to do
with the code that was available on the day they ran. As things are
fixed and new tests are released, there will be new results. But
MooTools can't disqualify the results because they haven't yet gotten
around to optimizing "tag.class", Nor can you.

However, the inclusion of not:, 2n, 2n + 1 is misleading as I never
claimed to support those.  That's why they are absent from my test page..
 Well, the first was never there in the first place.  I'm _not_ adding
that.  

I don't find much practical use for the general "A n + B" syntax, but
the even/odd "2n"/"2n + 1" selectors have been quite helpful to me.
Almost anytime I use selector engines, though, I find myself using
":not" a fair bit. Obviously it's up to you what you want to support,
but I'd urge you to reconsider.

In my testing, it has been shown to be relatively fast at those sorts of
simple queries.  The QSA version doesn't hand those off though (at least
not at the moment).  I've been considering doing that in the QSA add-on..

I'm surprised the native QSA engines aren't faster at these,
especially at "#id". If an external library can do a quick switch to
getElementById, you'd think the native engines could also do this in
order to speed things up.

The most important thing to take out of all of this is to not use
queries for anything.  It's the worst possible strategy, popular or not..

I'm curious as to why you (and others here, I've noted) say this.
I've found queries to be an incredibly useful tool, especially for
dynamic pages. What is the objection?

Like I've been saying, the TaskSpeed stuff is more compelling.

It is more compelling, but more subject to manipulation, I'm afraid.
Still it's worth pursuing, as long as we keep in mind that speed is
only one of a number of important concerns.

-- Scott

 

[Scott Sauyet]

Also, I am not sure why you guys are using API.getEBCS over and over.
The extra dot operation is unnecessary.  The whole reason the (not
recommended for GP use) $ is in there is for tests like these.  The
extra dot operation on each call just clouds the issue as you would
normally use something like this:-

var getEBCS = API.getEBCS;

...at the start.  The API is not made up of methods in the strict sense..
  The API is simply a "namespace" object containing the supported
functions (which vary according to the environment).  They are functions
that don't refer to - this - at all.

That makes sense, and I'll probably do that in future versions.
Unfortunately, I will have to add it to the mylib.js file, as I don't
want to adjust the simple configuration that exists right now, just
lines like this in a config file:

[MooTools 1.2.4]
file = "mootools-yui-compressed.js"
function = "$$"

[My Library]
file = "mylib-min.js"
function = "API.getEBCS"

But I am bothered by "The whole reason the (not recommended for GP
use) $ is in there is for tests like these." Having code that you
expect to be used for tests but not for general purposes strikes me as
an uncomfortable sort of pandering to the tests.

-- Scott

 

[Scott Sauyet]

LOL.  It appears that those last two are the same as even and odd
respectively.  I never bothered to look them up as I didn't plan to
support them.  Wouldn't have guessed they were aliases, but then now
that I think about it...  

In general, I would handle the An + B case, and make even/odd aliases
to 2n / 2n + 1 versions.

Suffice to say those will be "supported" shortly.  Quotes indicate I
have reproduced the "slow lane" issue with evens/odds using the test
document from Scott's site.  I'll fix that shortly.

Thanks for bringing that to my attention.  I still insist you remove the
not: test as I have no plans to support _that_.

I'm afraid that you have no standing for your insistence. If you
convince the maintainers of the original SlickSpeed tests to remove
them, I will certainly publish a version without it. Or you can
publish your own. I think the defacto standardization this list of
selectors offers is worth maintaining. You can chose whether or not
to offer support for it. But as I said in a recent post, I personally
find ":not" fairly useful.

-- Scott

 

[Scott Sauyet]

Scott Sauyet wrote:
Based on the SlickSpeed tests John-David Dalton recently demonstrated,
I've created my own new version of SlickSpeed.  It uses essentially
the same timer-loop method as he did, but then calculates and reports
the time per iteration in microseconds, totaling them in milliseconds
so that the final report looks more like the original one: smaller is
better again!    I've chosen to run the test repeatedly until it's
taken over 250 ms, which seems to give a reasonably good balance
between accuracy and performance; the original 40 selectors take about
10 seconds per library tested.
Okay.
There is still one flaw that Richard Cornford pointed out [1]: the
loop also includes repeated calls to "new Date()".  This will serveto
slow down all libraries and somewhat downplay the differences between
them.  I'm considering ways to fix it, but for the moment it shouldn't
affect rankings, only the speed ratios between the libraries.
Makes sense.  The difference is what matters.
My first pass at this is at:
   http://scott.sauyet.com/Javascript/Test/slickspeed/2010-02-12a/
I've tried it once so far (just now) in FF1 on XP Pro on a PC that is
over five years old.
 2013.922 ms    4572.244 ms     3763.426 ms     1618.309ms*    1431.766 ms*
 1665.66 ms     75786.916 ms
I don't know what happened with YUI.  But it was only one run.  Too many
pink boxes (slowest) to think it will come out of it though.  Prototype
didn't do too bad, but was disqualified for miscounting :contains
(unless they have stipulated that they do not support that selector).
I take issue with the inclusion of tests that are not supported by all
of the libraries.  Doesn't make a lot of sense as not every library
claims to support the exact same set of selectors.  For example, 2n and
2n + 1 are things I didn't feel like bothering with.  I just can't see
getting that silly with this stuff.  There are certainly many other CSS3
selectors that I do not (and will not) support for querying.  If you
want more than what is supported, write an add-on (it's very easy to do
as the QSA addition illustrates).
There is a link in the footer to a zip file containing the PHP code
used.
My raw results are below, run against recent versions of the major
browsers on a powerful Windows XP machine.
Okay.
While this is still not a
home run for My Library, it's definitely getting to be a closer
contest on my developer's machine, at least with QSA.
With QSA it will always be a tight race, likely so tight that the
differences are unimportant.  It's when the library has to "thunk" back
to DOM traversal that the difference vary widely.  And that's important
as most browsers in use today do not support QSA at all (and those that
do do it less than perfectly).
While I
understand and partially agree with John-David's objections to the
current My Library QSA code [2], I think it's good enough for this
sort of testing at the moment, and I doubt the fixes to it will change
much in the way of speed.
I think a lot of the "fixes" would simply be adding support for
selectors that I don't deem worthy of support.  Not all, of course, he
did notice some valid peculiarities and some of them have been fixed in
the interim.
The big news is that in these tests, in all browsers, except IE6 and
IE8 in compatibility mode, My Library (QSA) was the fastest for a
majority of the selectors.
I'm not surprised.  Nor am I surprised that broken MSHTML
implementations are the exceptions.  Those are where the wheels falloff
for every one of the others.  Put a few choice attribute-related rules
in and they will predictably break down and veer off the course.  And
these are obviously selectors they assert to support (and have asserted
so for some time).  That's not good, especially when Web developers are
now being conditioned to "forget" IE < 8 (and as we know, IE8
compatibility mode is roughly equivalent to IE7).
But in none was it the overall fastest.  JQuery was the fastest in
everything but IE6, where it came in third behind Dojo and MooTools.
In many browsers, if two of the selectors were optimized to match the
speed of the competition, My Library (QSA) would have been about the
fastest overall library.  Those were the two selectors with
":contains": "h1[id]:contains(Selectors)" and
"p:contains(selectors)".  In the various IE's there was a different
issue, "p:nth-child(even/odd)" were wrong in both versions of My
Library, and were significantly slower, too.
The even/odd discrepancy, which did not show up in my (obviously
incomplete) testing is a legitimate beef.  Apparently I managed to make
those both slow and incorrect.  It can happen.  I'll grab your test page
as an example and fix it when I get a chance.  Will also announce that
those two are broken in my forum.  As far as I am concerned, the results
are disqualified until those two are fixed.
However, the inclusion of not:, 2n, 2n + 1 is misleading as I never
claimed to support those.  That's why they are absent from my test page.
 Well, the first was never there in the first place.  I'm _not_ adding
that.  

LOL.  It appears that those last two are the same as even and odd
respectively.  I never bothered to look them up as I didn't plan to
support them.  Wouldn't have guessed they were aliases, but then now
that I think about it...  

Suffice to say those will be "supported" shortly.  Quotes indicate I
have reproduced the "slow lane" issue with evens/odds using the test
document from Scott's site.  I'll fix that shortly.

Thanks for bringing that to my attention.  I still insist you remove the
not: test as I have no plans to support _that_.

I fixed the two broken selectors (even/odd).  It was an oversight that I
accounted for the "!" tagName (comment) in all but those two pseudos.
Will update the Downloads page and repository shortly.

The 2n and 2n+1 aliases are now working (at least superficially-they are
just aliases for even/odd).  I guess I'll have to go ahead and
generalize them now.  Doesn't appear to be much of a chore.

I can publish a new version if you like. If you're working on that
generalization now, I'll hold off. Is this available at cinsoft?

Good idea to put some comments in the test document.    I imagine that
will settle some of the alien unit test issues as well.

Is that your own test document you're talking about or something you
thought I did for the SlickSpeed tests?

-- Scott

 

[Scott Sauyet]

I'm wondering if I should put something right on the page to point out
the different units; I'd rather not change any more of the original
than is necessary, which is why the totals row is reported in
milliseconds even though the individual items are in microseconds.
But yes, those numbers can be jarring at first!

Okay, time for a self-administered dope-slap. I should report all the
numbers in millisecond displayed with up to three decimal places, the
same way I display the totals. If I publish a new version, I will fix
that.

-- Scott

 

[Ivan S]

I've noticed an issue in Firefox 3.6

div, p, a 1337 µs 671 found 1387 µs 671 found 2551 µs 671 found 1832
µs 673 found 1190 µs 673 found 5050 µs 671 found 1256 µs 671 found

Mylib (non-QSA & QSA) found 673 element, while other libraries found
671.

In Chome 4:

div, p, a 740 µs 671 found 641 µs 671 found 1232 µs 671 found 1761 µs
671 found 539 µs 671 found 1092 µs 671 found 594 µs 671 found

Other browser also found 671 element for all libraries.

 

[Scott Sauyet]

I've noticed an issue in Firefox 3.6

div, p, a       1337 µs 671 found      1387 µs 671 found      2551 µs 671 found      1832
µs 673 found   1190 µs 673 found      5050 µs 671 found     1256 µs 671 found

Mylib (non-QSA & QSA) found 673 element, while other libraries found
671.

I cannot confirm this. I just upgraded to FF 3.6 and I'm not seeing
that.

In Chome 4:

div, p, a       740 µs 671 found       641 µs 671 found       1232 µs 671 found      1761 µs
671 found       539 µs 671 found       1092 µs 671 found      594 µs 671 found

Other browser also found 671 element for all libraries.

I don't have Chrome 4 and it's not easy for me to upgrade Chrome from
work. I will try tonight from home to see if I get the same results.
But this is pretty strange behavior, especially after you had issues
in Opera, too. I'm starting to wonder if your CPU forgot how to
count!

-- Scott

 

[Ivan S]

I cannot confirm this.  I just upgraded to FF 3.6 and I'm not seeing
that.

Ok, thanks to you I found what's causing that. It's Firefox add-on
called Adblock Plus (based on method of elimination).

But this is pretty strange behavior, especially after you had issues in Opera, too.  

Well ... hate to say, but I still have them.

My Opera is fresh instalation (I don't use it except for testing), so
I don't know why is this happening (expecially because it happens
randomly).

See it for yourself:

http://img12.imageshack.us/img12/6230/opera1e.jpg
http://img687.imageshack.us/img687/6645/opera2.jpg
http://img63.imageshack.us/img63/2237/opera3j.jpg

I'm starting to wonder if your CPU forgot how to count!