jQuery vs. My Library [JavaScript]

Prev: Could this be done in javascript?
Next: Passing primitives by reference, part 2

From: Andrew Poulos on 13 Feb 2010 14:50

On 13/02/2010 11:55 PM, Ivan S wrote:
> On Feb 12, 6:21 pm, Scott Sauyet<scott.sau...(a)gmail.com> wrote:

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

> Latest Opera (10.10) has a problem with Mylib without QSA and Dojo
> (all tests returned error).

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

p:only-child 27000 �s 3 found
201 �s 3 found

Andrew Poulos

From: David Mark on 14 Feb 2010 17:31

Andrew Poulos wrote:
> On 13/02/2010 11:55 PM, Ivan S wrote:
>> On Feb 12, 6:21 pm, Scott Sauyet<scott.sau...(a)gmail.com> wrote:
>
>>> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-02-12a/
>
>> Latest Opera (10.10) has a problem with Mylib without QSA and Dojo
>> (all tests returned error).

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
>
> p:only-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.

From: David Mark on 14 Feb 2010 17:42

From: David Mark on 14 Feb 2010 17:48

Scott Sauyet wrote:
> On Feb 9, 12:30 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>> On Jan 23, 8:05 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
>>> I think it's worth testing older libraries in various environments.
>>> What I objected to is the self-aggrandizing manner in which David
>>> Marks promoted the spped of his library, upgrading his library in the
>>> tests to the latest version, but leaving the other libraries with two-
>>> year old versions. You know he didn't expect anyone to notice.
>> That's complete bullshit.
>
> 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.

>
> On Jan 22, 5:56 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> | Scott Sauyet wrote:
> | > On Jan 22, 2:38 pm, David Mark <dmark.cins...(a)gmail.com> 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.

From: David Mark on 14 Feb 2010 18:32

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 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:
> ----
> dj:81 jq:71 mt:227 ml:689 mlqsa:366 pr518: yui:142
>
> Opera 10.10:
> -------------
> dj:19 jq:17 mt:58 ml:340 mlqsa:261 pr:27 yui:18
>
> Safari 4.0.4:
> -------------
> dj:8 jq:7 mt:26 ml:42 mlqsa:9 pr:9 yui:8
> =================================================================

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. ;)

First | Prev | Next | Last
Pages: 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Prev: Could this be done in javascript?
Next: Passing primitives by reference, part 2