From: S.T. on 9 Feb 2010 16:06 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. > 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 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 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
From: David Mark on 9 Feb 2010 16:08 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?
From: gf3 on 9 Feb 2010 16:19 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'
From: David Mark on 9 Feb 2010 16:35 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.
From: AlexSexton on 9 Feb 2010 16:42
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)... |