jQuery vs. My Library
in [JavaScript]
|
From: David Mark on 22 Jan 2010 18:27 David Mark wrote: > David Mark wrote: >> Scott Sauyet wrote: >>> On Jan 22, 2:38 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> Matt Kruse 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 >>> >>> Because I see several problems with it. If not, could you let us know >>> what page we should examine? >>> >>> The first problem I see is that you're comparing an up-to-date version >>> of My Library with a version of MooTools that came out in November, >>> 2007, a version of Prototype from January, 2008, and a version of >>> JQuery from May, 2008. That is certainly enough to invalidate the >>> results in the fast-moving world of JS libraries. >>> >>> Second of all, although slickspeed has numerous faults, it has >>> performed at least one useful service to the ecosystem of CSS selector >>> engines: it has helped to standardize the collection of selectors >>> libraries are expected to support. Instead of adding support for >>> these selectors, you simply remove 30% of the tests from the original >>> slickspeed. Five of those removed selectors cause errors in My >>> Library in recent versions of Firefox, Opera, and Webkit-based >>> browsers. >>> >>> And third, even among those selectors tested, there are two ("*", and >>> "div + div") for which My Library returns different values in every >>> browser than do the other libraries. I haven't gone and counted, and >>> perhaps My Library is correct, but I'd be surprised if each of the >>> other libraries got it wrong, yet all got identical values. >>> >>> I made two new versions based on the original slickspeed [1]. The >>> first one keeps intact the original selectors. It's at >>> >>> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/ >>> >>> I used the latest versions of Dojo, JQuery, MooTools, and Prototype >>> from: >>> >>> http://code.google.com/apis/ajaxlibs/ >>> >>> and the version of My Library posted here: >>> >>> http://www.cinsoft.net/mylib-min.js >>> >>> >>> My results, all on Win XP SP2 (results in milliseconds, low numbers >>> are better): >>> >>> Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib - >>> 30 >>> FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58, >>> MyLib - 75 >>> IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282, >>> MyLib - 46 >>> Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib >>> - 0 >>> Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30, >>> MyLib - 40 >>> >>> >>> The second version uses the set of selectors from the My Library >>> page. It's at >>> >>> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/ >>> >>> With the same testing configuration, my results were: >>> >>> Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib >>> - 13 >>> FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50, >>> MyLib - 53 >>> IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31, >>> MyLib - 0 >>> Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib - >>> 0 >>> Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22, >>> MyLib - 21 >>> >>> >>> This hardly looks like a win for My Library. >>> >> LOL. Here's a result from a relatively slow machine running FF1:- >> >> 999 1561 1107 842 358 >> >> The result is far more significant than the above (half of which are >> completely irrelevant) combined. > > Running it the latest Chrome, I did notice the two discrepancies. > Clearly this new test page has exposed some bugs. It can't be the same > content as the last one. I bet I'll fix them and they won't come back. > ;) I'm not shocked that there are bugs in there. I've never claimed > to have tested the CSS selector queries with any sort of seriousness > (I've stated the exact opposite numerous times here). > > Thing is, various people (who know who they are) should have been doing > what you are doing two years ago. That's how this project was supposed > to go. But never mind, no time like the present. I wouldn't bother > testing _unsupported_ selectors though. ;) > > 90 53 209 87 174 > > Not bad considering the others are using QSA (except perhaps Mootools, > which is still slower two years later). You have to test the fallback > branches to get an indication of how fast the query implementations are. > In fact, that's why my test page is actually better. It's the older, > slower, QSA-less browsers (and other agents) that will expose efficiency > problems. The new ones using QSA will all act about the same. As mine > is competitive even without QSA, it would seem to be the winner. ;) > > IE8: 109 15 7330 282 218 See what happens? :) You lost Mootools. The other differences are insignificant. In compatibility mode:- 344 454 4001 6860 328 Wow. Prototype and Mootools (latest versions) are unusable in IE8 compatibility mode. My Library is the clear winner, but not significantly faster than the other two. This is an older machine, but hardly a clunker. The slower the machine, the older the browsers, the wider the margin. Running such tests on blazing fast machines is a waste of time as the differences aren't significant enough to be palpable.
From: john on 22 Jan 2010 19:44 On 22 Jan 5:01 PM, David Mark wrote: > LOL. Here's a result from a relatively slow machine running FF1:- > > 999 1561 1107 842 358 > > The result is far more significant than the above (half of which are > completely irrelevant) combined. here are some more results. <http://www.cinsoft.net/mylib-testspeed.html> --- 54 122 112 38 # Opera 9.64 + 70 121 117 47 # Firefox 3.0.12 + 1 1964 184 2352 # iCab 3.0.5 + * 543 290 191 299 # Internet Explorer 6 - 547 278 187 274 # Internet Explorer 7 - 360 167 135 144 # Internet Explorer 8 - 53 51 1383 1362 # OmniWeb 5.1 + ** 940 661 591 611 # Netscape Navigator 6.2.3 - 1147 1451 1303 1377 # iPhone 3.1.2 (7D11) --- <http://www2.webkit.org/perf/slickspeed/> --- 14529 11520 5827 646 # Firefox 3.6 + 6059 6666 3916 225 # Safari 4.0.4 + 5806 8766 4825 647 # Opera 10.5 pre-alpha - 559 8201 4841 274 # Google Chrome 3.0.195.38 - :( # Internet Explorer 8 - *** --- clearly it is unfair to compare results which use a branch for QuerySelectorAll capable browsers and a different branch for "old" browsers. --- + tested on a relatively fast Mac Pro under "typical" (for me anyway) system load - tested in a VMWare virtual machine running XP SP3 with just the tested browser running. * My Library miscounts `div:last-child` while MooTools miscounts `div[class!=madeup]`. Prototype errors on everything and jQuery miscounts everything. ** MooTools and Prototype error on everything. OmniWeb 5.1 uses a forked version of WebKit from around about January 2005. *** i think Internet Explorer 8 may have a buggy/incomplete QSA implementation as it was unable to complete the tests. so i have to wonder what would happen if something like jQuery were to take the QSA branch on IE8. errors or a "the script on this page is running too slow" message i guess. does anyone know if they skip IE8s buggy/incomplete QSA implementation?
From: john on 22 Jan 2010 19:57 On 22 Jan 4:56 PM, David Mark wrote: > Scott Sauyet wrote: >> My results, all on Win XP SP2 (results in milliseconds, low numbers >> are better): > > Waste of time. They are all using QSA now, which is incompatible with > their "slow lane" branches. It's stupid. But I can add QSA too. It's > just silly to compare apples and oranges at the moment. my results confirm the futility of comparing results gathered from QSA and from the "slow lane" branch. i'd like to see you add QSA to My Library (and if possible make it aware of the possible quirks in the IE8 implementation of QSA).
From: David Mark on 22 Jan 2010 20:06 john wrote: > On 22 Jan 5:01 PM, David Mark wrote: >> LOL. Here's a result from a relatively slow machine running FF1:- >> >> 999 1561 1107 842 358 >> >> The result is far more significant than the above (half of which are >> completely irrelevant) combined. > > here are some more results. > > <http://www.cinsoft.net/mylib-testspeed.html> > --- > 54 122 112 38 # Opera 9.64 + Cool. > 70 121 117 47 # Firefox 3.0.12 + Cool. > 1 1964 184 2352 # iCab 3.0.5 + * Ah, two of the others bombed out. > 543 290 191 299 # Internet Explorer 6 - That's a horse race. Your VM is much faster than my real (slow) Wintel boxes. > 547 278 187 274 # Internet Explorer 7 - Definitely much faster than my test machines. > 360 167 135 144 # Internet Explorer 8 - Here we see the effect of taking the standard getAttribute branch. ;) And it's actually a horse race with jQuery (which is using QSA). > 53 51 1383 1362 # OmniWeb 5.1 + ** First two bombed out of course. > 940 661 591 611 # Netscape Navigator 6.2.3 - > 1147 1451 1303 1377 # iPhone 3.1.2 (7D11) Woohoo! We support phones too! And ours actually has a shot at working on them (due to the feature testing). Normal tasks (e.g. creating elements) should be light years ahead in terms of speed on slow moving mobile devices as well. > --- > > <http://www2.webkit.org/perf/slickspeed/> > --- > 14529 11520 5827 646 # Firefox 3.6 + I haven't seen that browser yet. Downloaded it, but haven't installed. > 6059 6666 3916 225 # Safari 4.0.4 + That's what I'm talking about. But this second set of tests is tainted by the unsupported (by My Library) selectors. Personally, I don't consider four or five scripts agreeing on one page to be a standard though. I say we shouldn't try to handle every one of them as most apps don't need them all. :) > 5806 8766 4825 647 # Opera 10.5 pre-alpha - > 559 8201 4841 274 # Google Chrome 3.0.195.38 - > :( # Internet Explorer 8 - *** > --- > > clearly it is unfair to compare results which use a branch for > QuerySelectorAll capable browsers and a different branch for "old" > browsers. Right. I should add the QSA support at some point, but I don't want to rush into it as I don't see how it will make any palpable difference on fast machines and I already own all of the old ones (and other lesser browsers), which don't have QSA anyway. So it can only buy incompatibility at the moment (something the others picked up in droves). > > --- > + tested on a relatively fast Mac Pro under "typical" (for me anyway) > system load > > - tested in a VMWare virtual machine running XP SP3 with just the tested > browser running. > > * My Library miscounts `div:last-child` while MooTools miscounts > `div[class!=madeup]`. Prototype errors on everything and jQuery > miscounts everything. > > ** MooTools and Prototype error on everything. OmniWeb 5.1 uses a forked > version of WebKit from around about January 2005. > > *** i think Internet Explorer 8 may have a buggy/incomplete QSA > implementation as it was unable to complete the tests. so i have to > wonder what would happen if something like jQuery were to take the QSA > branch on IE8. errors or a "the script on this page is running too slow" > message i guess. does anyone know if they skip IE8s buggy/incomplete QSA > implementation? I know they don't skip it entirely. More likely they skip it for a handful of cases where they've observed inconsistencies. Granted, that's a completely insane approach, but then history always repeats itself. ;) There's just no way any of these things should have dove into QSA. But then these five deluded groups of programmers think they are in some sort of significant arms race. They think people are too stupid to realize they are all on QSA now (except in older or lesser browsers where they are using something incompatible with QSA). These things are definitely going to die out soon (and I don't necessarily mean because of My Library).
From: David Mark on 22 Jan 2010 20:08
john wrote: > On 22 Jan 4:56 PM, David Mark wrote: >> Scott Sauyet wrote: >>> My results, all on Win XP SP2 (results in milliseconds, low numbers >>> are better): >> >> Waste of time. They are all using QSA now, which is incompatible with >> their "slow lane" branches. It's stupid. But I can add QSA too. It's >> just silly to compare apples and oranges at the moment. > > my results confirm the futility of comparing results gathered from QSA > and from the "slow lane" branch. i'd like to see you add QSA to My > Library (and if possible make it aware of the possible quirks in the IE8 > implementation of QSA). Will do if it turns out to be viable in IE8 (and it will definitely be optional). I'm going to fix the current branches first though (combinator problems it appears). |