TaskSpeed results for My Library
in [JavaScript]
|
From: David Mark on 9 Feb 2010 16:48 David Mark wrote: > gf3 wrote: >> On Feb 9, 4:08 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>> S.T. wrote: >>>> On 2/9/2010 12:36 PM, David Mark wrote: >>>>> Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your >>>>> language? >>>> It's testing ops/ms, so... yeah... bigger numbers are better. The "final >>>> ops/ms (more is better)" label in the final results is a big giveaway. >>> If I had bothered to pay attention to his folly, I would have seen that. >>> So what? >>> >>> And who knows what it is testing? Have you looked at the code? Do you >>> really think there is such a measurable difference between QSA calls? I >>> don't. >>> >>> >>> >>>>> And, of course, these tests must be run multiple times in a variety of >>>>> environments to indicate anything of substance. Still, it sure >>>>> doesn't look like "one of the slowest" from the early returns. ;) >>>> OK. Here's my results. >>>> On IE6 yours fairs alright. Behind JQuery/Sizzle and NWMatcher, but >>>> ahead of the others. Pretty close top-to-bottom here. >>>> 58 99 42 78* 126 114 47 >>> On that run. See above. >>> >>> >>> >>>> On Win/Chrome 4.0.249.78 yours is dead last, a little behind Mootools >>>> and Dojo, with the others well ahead. >>>> 517 1298 246 162* 2926 1780 1357 >>> Whatever that means. See above. >>> >>> >>> >>>> On Wn/FF3.6 dead last again, not far behind Mootools at least. >>>> 374 435 279 141* 1386 526 458 >>>> On IE8 you beat Mootools handily, behind to well-behind the rest. >>>> 209 435 64 143* 811 533 476 >>> Again. What makes you think these numbers have any meaning at all? >>> because "jdalton" said they did? >> >> WebKit Nightly Version 4.0.4 (6531.21.10, r54448) >> >> 834 1317 361 189* 2694 1934 1495 >> > > Great! Now if someone can explain why these numbers have any meaning at > all... Otherwise, they are just numbers. ;) > > My QSA wrapper is so thin that it makes me think these tests are bogus > or he used my QSA-less version. I don't have the interest to > investigate, but perhaps somebody else will. This is it:- // QSA add-on uses built-in queries var global = this; if (this.API && this.API.getEBCS && this.API.isHostMethod(this.document, 'querySelectorAll')) { (function() { var oldGetEBCS = this.API.getEBCS; var toArray; try { (Array.prototype.slice.call(global.document.querySelectorAll('html'), 0)); toArray = function(a) { return Array.prototype.slice.call(a, 0); }; } catch(e) { toArray = API.toArray; } this.API.getEBCS = function(s, d) { try { return toArray((d || global.document).querySelectorAll(s)); } catch(e) { return oldGetEBCS(s, d); } }; if (typeof $ == 'function') { $ = this.API.getEBCS; } })(); } Other than the try-catch, I don't see anything between the script and the browser's built-in queries. The toArray function will be like lightning in the tested browsers (excluding IE) as well. So what can these numbers possibly indicate (aside from the fact that "jdalton" considers them more "accurate" than the original SlickSpeed tests). I predict it is all a waste of time. ;) Meanwhile, jQuery still can't read (documents) and "jdalton" is making a fool of himself on Twitter. There's progress. :)
From: David Mark on 9 Feb 2010 16:50 AlexSexton wrote: > On Feb 9, 3:19 pm, gf3 <giannichiappe...(a)gmail.com> wrote: >> On Feb 9, 4:08 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> >> >> >> >> >>> S.T. wrote: >>>> On 2/9/2010 12:36 PM, David Mark wrote: >>>>> Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your >>>>> language? >>>> It's testing ops/ms, so... yeah... bigger numbers are better. The "final >>>> ops/ms (more is better)" label in the final results is a big giveaway. >>> If I had bothered to pay attention to his folly, I would have seen that. >>> So what? >>> And who knows what it is testing? Have you looked at the code? Do you >>> really think there is such a measurable difference between QSA calls? I >>> don't. >>>>> And, of course, these tests must be run multiple times in a variety of >>>>> environments to indicate anything of substance. Still, it sure >>>>> doesn't look like "one of the slowest" from the early returns. ;) >>>> OK. Here's my results. >>>> On IE6 yours fairs alright. Behind JQuery/Sizzle and NWMatcher, but >>>> ahead of the others. Pretty close top-to-bottom here. >>>> 58 99 42 78* 126 114 47 >>> On that run. See above. >>>> On Win/Chrome 4.0.249.78 yours is dead last, a little behind Mootools >>>> and Dojo, with the others well ahead. >>>> 517 1298 246 162* 2926 1780 1357 >>> Whatever that means. See above. >>>> On Wn/FF3.6 dead last again, not far behind Mootools at least. >>>> 374 435 279 141* 1386 526 458 >>>> On IE8 you beat Mootools handily, behind to well-behind the rest. >>>> 209 435 64 143* 811 533 476 >>> Again. What makes you think these numbers have any meaning at all? >>> because "jdalton" said they did? >> WebKit Nightly Version 4.0.4 (6531.21.10, r54448) >> >> 834 1317 361 189* 2694 1934 1495 >> >> Jussayin' > > MyLibrary in my tests: > > latest Chrome (5.0.317.2)/Vista-x64 > 592 1290 296 202* 3276 1796 1403 > > Firefox 3.6 > 321 395 269 149* 1260 458 419 > > IE8: > 193 383 58 128* 708 479 404 > > Hell, I'll set up a jdalton tribute site if it makes David Mark wrong > (again)... That's what all of this comes down to? Proving me "wrong?" LOL. Amazing how the losers come out of the woodwork when they think they've found an in. What do these numbers mean to you, other than they somehow prove that I am "wrong?" :)
From: jdalton on 9 Feb 2010 17:08 Hi David, > The QSA add-on is not needed as > the library is certainly fast enough without it. You said yourself your QSA add-on isn't needed you also don't have it as an option in your build system (or I couldn't find it) > Other than the try-catch, I don't see anything between the script and > the browser's built-in queries. That's a problem because QSA is buggy across all browsers and you don't attempt to fix anything. Also many of these selector engines bypass QSA, for simple queries, altogether. Here are test results not effected by QSA IE 7.0.5730.11 32 51 21 39* 73 59 26 IE 6.0.2900.5122.xpsp_sp3.gdr.080814-1236 30 50 20 38* 75 59 26 IE 8.0.6001.18702 (Compatibility View) 56 91 33 72* 216 108 62 Opera 9.50 (build 10063) 160 150 55 *68 339 170 128
From: David Mark on 9 Feb 2010 17:10 AlexSexton wrote: > On Feb 9, 3:19 pm, gf3 <giannichiappe...(a)gmail.com> wrote: >> On Feb 9, 4:08 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> >> >> >> >> >>> S.T. wrote: >>>> On 2/9/2010 12:36 PM, David Mark wrote: >>>>> Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your >>>>> language? >>>> It's testing ops/ms, so... yeah... bigger numbers are better. The "final >>>> ops/ms (more is better)" label in the final results is a big giveaway. >>> If I had bothered to pay attention to his folly, I would have seen that. >>> So what? >>> And who knows what it is testing? Have you looked at the code? Do you >>> really think there is such a measurable difference between QSA calls? I >>> don't. >>>>> And, of course, these tests must be run multiple times in a variety of >>>>> environments to indicate anything of substance. Still, it sure >>>>> doesn't look like "one of the slowest" from the early returns. ;) >>>> OK. Here's my results. >>>> On IE6 yours fairs alright. Behind JQuery/Sizzle and NWMatcher, but >>>> ahead of the others. Pretty close top-to-bottom here. >>>> 58 99 42 78* 126 114 47 >>> On that run. See above. >>>> On Win/Chrome 4.0.249.78 yours is dead last, a little behind Mootools >>>> and Dojo, with the others well ahead. >>>> 517 1298 246 162* 2926 1780 1357 >>> Whatever that means. See above. >>>> On Wn/FF3.6 dead last again, not far behind Mootools at least. >>>> 374 435 279 141* 1386 526 458 >>>> On IE8 you beat Mootools handily, behind to well-behind the rest. >>>> 209 435 64 143* 811 533 476 >>> Again. What makes you think these numbers have any meaning at all? >>> because "jdalton" said they did? >> WebKit Nightly Version 4.0.4 (6531.21.10, r54448) >> >> 834 1317 361 189* 2694 1934 1495 >> >> Jussayin' > > MyLibrary in my tests: > > latest Chrome (5.0.317.2)/Vista-x64 > 592 1290 296 202* 3276 1796 1403 > > Firefox 3.6 > 321 395 269 149* 1260 458 419 > > IE8: > 193 383 58 128* 708 479 404 > > Hell, I'll set up a jdalton tribute site if it makes David Mark wrong > (again)... Make sure you mention he's a squirrelly, obsessed cheater. :) 1. As I suspected, he is comparing their QSA with my stock library (without the QSA add-on). Duh, of course that will make a difference in these tests. Don't see how that proves me "wrong" about anything though. Proves him disingenuous (and foolhardy) for sure. ;) 2. He's got an (obviously unneeded) extra dot operation in each call to mine. Sabotage or stupidity, it really doesn't matter. This guy has all the credibility of... hell, I can't think of anyone less credible. VK? Why would anyone go to this much trouble to look like an idiot? I wonder how many more losers will show up to celebrate this great "victory" for incompetence over understanding? Also, the build he used is 32K _before_ minification, so that supports the conciseness angle. I suppose I should use such a build on my site to eliminate confusion about file sizes. In any event, this is hardly science. ;)
From: David Mark on 9 Feb 2010 17:21
jdalton wrote: > Hi David, > >> The QSA add-on is not needed as >> the library is certainly fast enough without it. > You said yourself your QSA add-on isn't needed you also don't have it > as an option in your build system (or I couldn't find it) I know what I said and I stand by it. It isn't needed at all. The "standard" TaskSpeed tests bear this out as they are closer to approximating what an application will do. Your version of SlickSpeed is obviously going to be affected, but who cares? > >> Other than the try-catch, I don't see anything between the script and >> the browser's built-in queries. > That's a problem because QSA is buggy across all browsers and you > don't attempt to fix anything. So? Of course, it still passes all of these tests. I'll deal with feature testing QSA when I get around to it. As I've mentioned, QSA isn't needed. And adding one-off feature tests won't affect any of the speed tests cited so far as they already _pass_ (so there will be no bypass). And are you really congratulating the "majors" for stacking one patchwork on top of another? Does that make any sense at all? I know it makes sense to them as they think they have to "keep up" with each other. The reality is that each layer is full of bugs, particularly the ones they've been working on non-stop for years (DOM traversal and XPath). Now they are off on another tangent. How does that help anything but their egos? Users don't really care (or know) about speed tests. > Also many of these selector engines > bypass QSA, for simple queries, altogether. Yes, they call gEBI, gEBTN, etc., just as I do in the "slow lane". What's your point? > > Here are test results not effected by QSA > > IE 7.0.5730.11 > 32 51 21 39* 73 59 26 > > IE 6.0.2900.5122.xpsp_sp3.gdr.080814-1236 > 30 50 20 38* 75 59 26 > > IE 8.0.6001.18702 (Compatibility View) > 56 91 33 72* 216 108 62 Interesting you went with an (almost) all-IE line-up this time. More chicanery? And don't talk to me about IE compatibility view. None of the others came close to working in IE8's various modes and they spent months working with the Beta versions, twiddling their browser sniffing, etc. In contrast, I did _nothing_ and was pleasantly surprised when _everything_ still worked on first load in IE8. ;) > > Opera 9.50 (build 10063) > 160 150 55 *68 339 170 128 Looks pretty inconclusive (not to mention spotty) now. So much for your "more accurate" tests. ;) Where's Webkit? |