TaskSpeed results for My Library
in [JavaScript]
|
From: gf3 on 9 Feb 2010 17:22 On Feb 9, 5:10 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > 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. ;) Well, at least you're humble.
From: David Mark on 9 Feb 2010 17:23 gf3 wrote: [...] >> In any event, this is hardly science. ;) > > Well, at least you're humble. You seemed to have missed something as that response makes no sense in context. And get a real name. Who is going to listen to initials?
From: S.T. on 9 Feb 2010 17:32 On 2/9/2010 2:23 PM, David Mark wrote: > And get a real name. Who is going to listen to initials? I will!
From: David Mark on 9 Feb 2010 17:28 S.T. wrote: > On 2/9/2010 2:23 PM, David Mark wrote: > >> And get a real name. Who is going to listen to initials? > > I will! But then who will listen to you? :(
From: David Mark on 9 Feb 2010 17:37
David Mark wrote: [...] > > "mylib.js API.getElementSizeStyle may resize elements to 0,0 for > browsers that don't compute style of hidden elements" > > Complete and utter nonsense. It's the only solution out there that > deals with variations in box models (e.g. IE quirks mode) and it > certainly does not resize elements to 0,0 as you suggest. Also, I am > sure you meant elements with display style of "none", not "hidden" > elements. Get your terms straight. ;) > And furthermore, if he bothered to pay attention here, he would know that I frequently ridicule the "majors" for jumping through hoops to "normalize" the height/width of elements that are not part of the layout. Hint: elements that are not part of the layout have no height/width (or can be considered 0,0). So once again, "jdalton" has identified a non-bug. He's showing his roots as most of these are the sorts of things Prototype wasted time on over the years, rather than trying to fix the problems that matter. I will address this in the documentation (where it belongs). Trust me in that you do not want such "normalization" as it hides mistakes in the calling app (e.g. you shouldn't be trying to measure elements that have no actual dimensions). ;) JQuery is even more ludicrous in that it "normalizes" CSS height/width to fit the one box model they've heard of. So there is really nothing practical you can do with the measurement (e.g. adjust it). :) Credit to MooTools for not going down this particular road to nowhere. It's the one thing they did right. :) |