TaskSpeed results for My Library
in [JavaScript]
|
From: David Mark on 9 Feb 2010 01:26 On Feb 4, 4:04 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote: > On 5/02/2010 3:45 AM, Andrea Giammarchi wrote: > > > > >> Cheers, > > >> -- Scott > > > and which library outperform PureDOM? Aren't we talking about that > > post with my massive comment inside removed/filtered? > > Under TaskSpeed, on Vista SP 2 with Safari 4.04 "My Library" was faster > than PureDom - 168 versus 246. > Should be noted that multiple tests must be run and the results averaged to get a fair representation. I see a lot of posts that appear to be one-off runs, which may or may not be good indications. No question that My Library is faster than the "pure" tests in Webkit though (by a long stretch), even with the unnecessary overhead of the OO interface.
From: David Mark on 9 Feb 2010 01:40 On Feb 4, 8:33 pm, RobG <rg...(a)iinet.net.au> wrote: [...] > > One of the main claims about libraries is that they smooth over > browser quirks. It might be interesting to develop a suite of > "QuirksSpeed" tests of known differences between browsers to determine > how well each library manages to overcome them. The overall speed is > likely not that important, quirks accommodated and correctly dealt > with likely are. > I agree 100%. That is where most of them fail miserably (e.g. jQuery "punts" on IE quirks mode, none of them handle attributes properly, etc.) And sniffing the UA string must result in a disqualification. I'm working on something like that, but I can't find too many that eschew the UA string. They give up much too easily in the name of "getting things done" (which translates to "not getting anything done" in reality).
From: jdalton on 9 Feb 2010 14:16 Hi David, > Other libraries unit tests are inconsequential at this stage. They still cover bugs and browser issues that your library fails to cover. > Don't be stupid. > I've submitted lots of bug reports to the other > libraries. They are hesitant to change anything as > they don't seem to understand anything they have done Reporting bugs is good. They (Dojo) will fix them on their timeline not yours. Twitter spamming them won't help. > That's not a bug. There's no crutch for the IE Again, the tests show you have bugs in lots of areas. > No, I don't have the problem at all. The QSA add-on is not needed as > the library is certainly fast enough without it. Other's Up-to-date CSS engines beat yours, in speed and compatibility, with or without QSA. > I don't want you to report bugs to me, nor have I asked you to. I > don't need your help. Is that clear enough? Good. > (particularly TaskSpeed, > where my optimized-for-conciseness tests beat the "baseline" PureDom > handily). If your tests are beating PureDom you A) have done your tests incorrectly or B) there is a problem with PureDom. > Have you read _anything_ I've written? Unfortunately I have. Your writings are mostly long multi-post/page rants where you reply to yourself or aliases. Repeat the same tired arguments over and over again, sprinkle in some name calling/insults, and you have a classic David Mark post. > And failing? Yes, your library has bugs in many browsers and versions of browsers. So many, in fact, visitors to your g-group, who seem to be relatively new to JS, point them out over and over again. > They've long since been updated. And what business is it of yours? > I still contend the old speed tests are far more telling than comparing > QSA results. ;) .... > Not really. 90% of the SlickSpeed tests take 0ms in the environments You should try a modified form of SlickSpeed that test max executions per ms, instead of 3 or so calls per test. This gives a more accurate indication of performance. You will find that your library is actually one of the slowest. Example: http://davidmissedthemark.com/slickspeed/ > No reluctance at all. I don't need to worry about unit tests written > by others at the time. Again, you are missing several basic bug fixes/browser issues because you refuse to look at others tests.
From: David Mark on 9 Feb 2010 14:49 On Feb 9, 2:16 pm, jdalton <john.david.dal...(a)gmail.com> wrote: > Hi David, > > > Other libraries unit tests are inconsequential at this stage. > > They still cover bugs and browser issues that your library fails to > cover. You have a very child-like view of this. If I decide (as I did) to _not_ allow bizarre markup (e.g. names and ID's that are the same for different elements), that is my design choice. I want the developer to know they are screwing up in that case. Other libraries took a different tack. That's why it makes little sense to test my design against their unit tests. Certainly you can't take the results at face value. What is reported as an "error" may well be intended by the designer. Get it? > > > Don't be stupid. > > I've submitted lots of bug reports to the other > > libraries. They are hesitant to change anything as > > they don't seem to understand anything they have done > > Reporting bugs is good. They (Dojo) will fix them on their timeline > not yours. Twitter spamming them won't help. You aren't following (and are clearly out of that loop). They tried to fix them and could never get past the understanding stage. I asked them to define what attr does and they said "it does what it does in FF". There's no hope with that sort of thinking. The _owners_ of Dojo are who asked me to step in and pound these points home, so mind your own business. ;) > > > That's not a bug. There's no crutch for the IE > > Again, the tests show you have bugs in lots of areas. See above. What you see as a bug may not be a bug at all. I will tell you when I have a chance to look at whatever it is you are looking at. I'm quite familiar with, for example, Dojo's unit tests and some of them sniff the UA string, so don't look at them as magical indicators. They are just code and in many cases may not be suitable for my design, which varies wildly from theirs. > > > No, I don't have the problem at all. The QSA add-on is not needed as > > the library is certainly fast enough without it. > > Other's Up-to-date CSS engines beat yours, in speed and compatibility, > with or without QSA. That's a completely worthless statement. And you know it is patently untrue if you know the first thing about the DOM (and have read any of their DOM-level code). They can't even get _IE_ right after ten years of relative quiet on that front. And IE8 is out of the question (that's when things predictably went from bad to impossible). http://www.cinsoft.net/attributes.html > > > I don't want you to report bugs to me, nor have I asked you to. I > > don't need your help. Is that clear enough? > > Good. > > > (particularly TaskSpeed, > > where my optimized-for-conciseness tests beat the "baseline" PureDom > > handily). > > If your tests are beating PureDom you A) have done your tests > incorrectly or B) there is a problem with PureDom. B. PureDom is just a script and it is clearly not optimal. Not only that, but the various test functions for each library are apples and oranges. So don't look at those tests as magic either. > > > Have you read _anything_ I've written? > > Unfortunately I have. Your writings are mostly long multi-post/page > rants where you reply to yourself or aliases. That's complete fiction. I've got almost 4000 posts here and maybe two come from a (well-advertised) alias, due to Google's idiotic posting limits. Please try to pay attention. > Repeat the same tired > arguments over and over again, sprinkle in some name calling/insults, The same tired scripts are out there fumbling and bumbling, year after year. Perhaps we should all just ignore their seemingly endless failings? I, for one, am tired of sites that fall apart for no reason, other than the developers wanted to be "hip" and use a "cool" (read: dubious) JS library. > and you have a classic David Mark post. You talk about nothing but David Mark, with a few generalizations about CSS selector engines thrown in. That's worthless noise by any standard in a technical discussion group. > > > And failing? > > Yes, your library has bugs in many browsers and versions of browsers. Another worthless generalization. All things relative, it's far more solid than anything out there. It's not even comparable to the "majors" as they all use the same stupid design that short-circuits the ability to do progressive enhancement. > So many, in fact, visitors to your g-group, who seem to be relatively > new to JS, point them out over and over again. You really are a disingenuous idiot. Are you referring to the users who are testing ancient browsers (per my request?) No kidding they found some gaps in the degradation paths and I fixed them all virtually instantaneously. Compare that to the "majors" that still can't get the latest version of IE anywhere near straight and take forever to move on anything, preferring to argue and whine that they are being embarassed by all of the "complaints". > > > They've long since been updated. And what business is it of yours? > > I still contend the old speed tests are far more telling than comparing > > QSA results. ;) > ... > > Not really. 90% of the SlickSpeed tests take 0ms in the environments > > You should try a modified form of SlickSpeed that test max executions > per ms, I should try a modified version of SlickSpeed? Why? > instead of 3 or so calls per test. This gives a more accurate > indication of performance. In what sense? > You will find that your library is actually > one of the slowest. > > Example:http://davidmissedthemark.com/slickspeed/ According to whatever nonsensical theory you have come up with about CSS selector engines (which are a stupid idea to begin with). I haven't tried your link. Is that a joke, or did you really create a tribute page? You've clearly got too much time on your hands (and a fixation on me for some reason). Good luck with it! > > > No reluctance at all. I don't need to worry about unit tests written > > by others at the time. > > Again, you are missing several basic bug fixes/browser issues because > you refuse to look at others tests. Again, see above.
From: David Mark on 9 Feb 2010 15:20
On Feb 9, 2:16 pm, jdalton <john.david.dal...(a)gmail.com> wrote: [...] > You should try a modified form of SlickSpeed that test max executions > per ms, instead of 3 or so calls per test. This gives a more accurate > indication of performance. You will find that your library is actually > one of the slowest. Example:http://davidmissedthemark.com/slickspeed/ > As I expected, you have no idea what you are talking about. From your twitter account:- "mylib-domready.js will fail if inline script/html comment has text `</ body>` or if the output buffer is flushed" Nonsense. If you knew anything, you would know that the test for "</ body>" is superfluous. It doesn't do anything and will be removed whenever I feel like it. And I've advised anyone who has asked (here) not to use that add-on as I don't believe it is a good idea (in any form). "mylib.js returns wrong for`Array.prototype.x=(a=[]).x=1; isOwnProperty(a,'x')` and `isOwnProperty(a,'nonexistant')" That's been answered too (somebody brought it up in my forum). It's not _wrong_ as the function is not designed to deal with such ill- advised prototype augumentations. About the worst thing you could say is my documentation isn't specific enough about such things (as I've admitted many times here). "mylib.js API.every, API.filter, API.map, API.push, & API.some don't follow spec causing cross-browser inconsistencies" API.push doesn't use the native Array.prototype.push, so throw that one out. And, yeah, I really should document (the previously mentioned) cases where the deviations occur with the others (I am well aware of them). Or maybe I will go ahead and put the extra code in to handle cases that are basically academic (e.g. undefined values are skipped due to my purposeful avoidance of the - in - operator). "A is for Awkward. mylib.js API.setAttribute erases element event observers when name/type attributes are set in IE." As mentioned, and discussed here dating back two years, changing the type and/or name is a novelty (came up on discussing INPUT elements and the IE bug related to DOM collections). And it's laughable that you would bring up attributes in IE. The others are completely off the map when it comes to those. Have a look at what jQuery, YUI, Dojo, etc. do. Now those are issues that will actually come up (and for a lot more than two attributes). ;) And I contend that it does not erase "observers" that were set with My Library. I am quite sure I will remove that novelty altogether when I have a chance, which will make this a moot point. "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. ;) "mylib.js attempts to support IE4 (~13yrs old) but fails to support Safari 2 (~5yrs old) in API.getDocumentWindow" I've never "attempted" to support IE4, or mentioned virtually anything about it (other than I can't get it to run in XP). Where do you get this stuff? And if getDocumentWindow is unfeasible in the current environment (whatever it may be), it is "pruned" from the API, along with anything that relies on it. The others just present the same static API and allow the calling app to blunder into an exception. Get it? "mylib.js API.addScript called in the HEAD elem throw an `Operation Aborted` error in IE6 when a page has a BASE" You really like the novelties, huh? That's also a purely academic exercise (and based on Randy Webb's tireless work on the subject). If IE6 throws an exception when a BASE element is present, it is a bug in IE6 that should be documented (by both MS and myself). Thanks! 'Hahaha davidmissedthemark.com" Hey, you've got a friend! But just look at him. :( "mylib.js css selector engine, getEBCS(), fails a massive amount of Prototype unit tests" We've been over that. Using another script's tests agsinst my design is ludicrous. Taking the results of such a tests at face value is completely disingenuous. I will evaluate the results when I have time. Thanks for your concern (but not your ill-gotten conclusions). "mylib.js API.getComputedStyle converts pt & em units to px but fails to do so for inch & cm units in IE" Another novelty! That whole hack is just begging to be removed. Realize I wrote most of this stuff over two years ago (and, as mentioned repeatedly, I was laboring under some misconceptions at the time). "mylib.js getEBCS() fails tons of jQuery tests on one & bombs the second." There you go again. See above. "mylib.js API.getEBCS fails ~650 Dojo, YUI, Google Closure & Slick unit tests" Parse error. :) Nice try, but beetle-browed babbling from an obviously ignorant nitwit isn't helping anything. Thanks for the one or two (possibly) legitimate bugs you have reported so far. :) |