jQuery vs. My Library
in [JavaScript]
|
From: David Mark on 14 Feb 2010 19:23 Scott Sauyet wrote: > Based on the SlickSpeed tests John-David Dalton recently demonstrated, > I've created my own new version of SlickSpeed. [...] Also, I am not sure why you guys are using API.getEBCS over and over. The extra dot operation is unnecessary. The whole reason the (not recommended for GP use) $ is in there is for tests like these. The extra dot operation on each call just clouds the issue as you would normally use something like this:- var getEBCS = API.getEBCS; ....at the start. The API is not made up of methods in the strict sense. The API is simply a "namespace" object containing the supported functions (which vary according to the environment). They are functions that don't refer to - this - at all.
From: David Mark on 14 Feb 2010 19:38 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_.
From: David Mark on 14 Feb 2010 21:21 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. Good idea to put some comments in the test document. :) I imagine that will settle some of the alien unit test issues as well.
From: David Mark on 14 Feb 2010 23:19 Andrew Poulos wrote: > On 13/02/2010 11:55 PM, Ivan S wrote: >> On Feb 12, 6:21 pm, Scott Sauyet<scott.sau...(a)gmail.com> wrote: > >>> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-02-12a/ > >> Latest Opera (10.10) has a problem with Mylib without QSA and Dojo >> (all tests returned error). That must have been in the test page. Opera 10.10 works fine for me on XP. 152 76 239 266 247 48 436 36 79 60* 60* That's on my SlickSpeed page. I'll test Scott's once he updates it with the even/odd fix.
From: David Mark on 14 Feb 2010 23:23
David Mark wrote: > Andrew Poulos wrote: >> On 13/02/2010 11:55 PM, Ivan S wrote: >>> On Feb 12, 6:21 pm, Scott Sauyet<scott.sau...(a)gmail.com> wrote: >>>> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-02-12a/ >>> Latest Opera (10.10) has a problem with Mylib without QSA and Dojo >>> (all tests returned error). > > That must have been in the test page. Opera 10.10 works fine for me on XP. > > 152 76 239 266 247 48 436 36 79 60* 60* > Oops. Just one of those sixties should be marked (the latter). On the initial run, it looks like the other QSA-enabled browsers came up slightly faster (and one tied). |