jQuery vs. My Library
in [JavaScript]
|
From: Scott Sauyet on 15 Feb 2010 09:54 On Feb 14, 7:38 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > David Mark wrote: >> 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. :) > > LOL. It appears that those last two are the same as even and odd > respectively. I never bothered to look them up as I didn't plan to > support them. Wouldn't have guessed they were aliases, but then now > that I think about it... :) In general, I would handle the An + B case, and make even/odd aliases to 2n / 2n + 1 versions. > Suffice to say those will be "supported" shortly. Quotes indicate I > have reproduced the "slow lane" issue with evens/odds using the test > document from Scott's site. I'll fix that shortly. > > Thanks for bringing that to my attention. I still insist you remove the > not: test as I have no plans to support _that_. I'm afraid that you have no standing for your insistence. If you convince the maintainers of the original SlickSpeed tests to remove them, I will certainly publish a version without it. Or you can publish your own. I think the defacto standardization this list of selectors offers is worth maintaining. You can chose whether or not to offer support for it. But as I said in a recent post, I personally find ":not" fairly useful. -- Scott
From: Scott Sauyet on 15 Feb 2010 09:56 On Feb 14, 9:21 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > David Mark wrote: > > David Mark wrote: > >> 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. :) > > > LOL. It appears that those last two are the same as even and odd > > respectively. I never bothered to look them up as I didn't plan to > > support them. Wouldn't have guessed they were aliases, but then now > > that I think about it... :) > > > Suffice to say those will be "supported" shortly. Quotes indicate I > > have reproduced the "slow lane" issue with evens/odds using the test > > document from Scott's site. I'll fix that shortly. > > > Thanks for bringing that to my attention. I still insist you remove the > > not: test as I have no plans to support _that_. > > I fixed the two broken selectors (even/odd). It was an oversight that I > accounted for the "!" tagName (comment) in all but those two pseudos. > Will update the Downloads page and repository shortly. > > The 2n and 2n+1 aliases are now working (at least superficially-they are > just aliases for even/odd). I guess I'll have to go ahead and > generalize them now. Doesn't appear to be much of a chore. I can publish a new version if you like. If you're working on that generalization now, I'll hold off. Is this available at cinsoft? > Good idea to put some comments in the test document. :) I imagine that > will settle some of the alien unit test issues as well. Is that your own test document you're talking about or something you thought I did for the SlickSpeed tests? -- Scott
From: Scott Sauyet on 15 Feb 2010 10:03 On Feb 15, 8:38 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Feb 14, 5:42 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> And I see this new test page uses _much_ higher numbers (and different >> units). I thought I was seeing things before I read the rest of the >> thread. :) > > I'm wondering if I should put something right on the page to point out > the different units; I'd rather not change any more of the original > than is necessary, which is why the totals row is reported in > milliseconds even though the individual items are in microseconds. > But yes, those numbers can be jarring at first! Okay, time for a self-administered dope-slap. I should report all the numbers in millisecond displayed with up to three decimal places, the same way I display the totals. If I publish a new version, I will fix that. -- Scott
From: Ivan S on 15 Feb 2010 11:44 I've noticed an issue in Firefox 3.6 div, p, a 1337 µs 671 found 1387 µs 671 found 2551 µs 671 found 1832 µs 673 found 1190 µs 673 found 5050 µs 671 found 1256 µs 671 found Mylib (non-QSA & QSA) found 673 element, while other libraries found 671. In Chome 4: div, p, a 740 µs 671 found 641 µs 671 found 1232 µs 671 found 1761 µs 671 found 539 µs 671 found 1092 µs 671 found 594 µs 671 found Other browser also found 671 element for all libraries.
From: Scott Sauyet on 15 Feb 2010 12:00
On Feb 15, 11:44 am, Ivan S <ivan.sku...(a)gmail.com> wrote: > I've noticed an issue in Firefox 3.6 > > div, p, a 1337 µs 671 found 1387 µs 671 found 2551 µs 671 found 1832 > µs 673 found 1190 µs 673 found 5050 µs 671 found 1256 µs 671 found > > Mylib (non-QSA & QSA) found 673 element, while other libraries found > 671. I cannot confirm this. I just upgraded to FF 3.6 and I'm not seeing that. > In Chome 4: > > div, p, a 740 µs 671 found 641 µs 671 found 1232 µs 671 found 1761 µs > 671 found 539 µs 671 found 1092 µs 671 found 594 µs 671 found > > Other browser also found 671 element for all libraries. I don't have Chrome 4 and it's not easy for me to upgrade Chrome from work. I will try tonight from home to see if I get the same results. But this is pretty strange behavior, especially after you had issues in Opera, too. I'm starting to wonder if your CPU forgot how to count! :-) -- Scott |