My Library TaskSpeed tests updated
in [JavaScript]
|
From: David Mark on 11 Feb 2010 23:22 I've updated the TaskSpeed test functions to improve performance. This necessitated some minor additions (and one change) to the OO interface as well. I am pretty happy with the interface at this point, so will set about properly documenting it in the near future. http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/94bcbd95caa03991 I had been thinking about what to do with cloneNode in the OO interface. All of the talk about PureDom's non-use of it gave me some ideas on how it could fit in and speed up these tests as well. The change is that E.prototype.clone no longer returns a wrapped node (not sure why I had it doing that in the first place as it has been a while since I slapped these objects together). Objects design is considerably less slap-dash now too. Almost all methods are on the prototypes now. There were a dozen or so that were being added at construction. It wasn't a big issue, but required that inheriting constructors call the "super" constructor on construction (which isn't always desirable). For example, F (form) inherits from E, but implements custom element and load methods. C (control) inherits from E, but uses the stock methods. F = function(i, docNode) { var el; if (this == global) { return new F(i, docNode); } // Custom element/load methods get and set the element function element() { return el; } this.load = function(name, docNode) { el = typeof name == 'object' ? name : getForm(name, docNode); this.element = (el)?element:null; return this; }; this.load(i, docNode); }; C = function(i, docNode) { // Called without - new - operator if (this == global) { return new C(i, docNode); } // Uses stock E element/load methods E.call(this, i, docNode); }; I'm no OO guru (or even fan), but I am happy with the way interface has turned out. One nagging incongruity is that (as noted in the documentation), you _must_ use the - new - operator when calling from outside the frame containing the My Library script (sort of like dialing the area code for a long-distance call). Functions are a bit more concise now too. The methods names are still relatively verbose (which is not central to the issue IMO), but there aren't as many calls to them now (which is what I consider the determining factor for conciseness). Fewer calls makes for a lower bill. ;) Your move, Andrea. Do your worst. :)
From: David Mark on 14 Feb 2010 23:45 David Mark wrote: > I've updated the TaskSpeed test functions to improve performance. This > necessitated some minor additions (and one change) to the OO interface > as well. I am pretty happy with the interface at this point, so will > set about properly documenting it in the near future. > > http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/94bcbd95caa03991 > > I had been thinking about what to do with cloneNode in the OO interface. > All of the talk about PureDom's non-use of it gave me some ideas on how > it could fit in and speed up these tests as well. The change is that > E.prototype.clone no longer returns a wrapped node (not sure why I had > it doing that in the first place as it has been a while since I slapped > these objects together). > > Objects design is considerably less slap-dash now too. Almost all > methods are on the prototypes now. There were a dozen or so that were > being added at construction. It wasn't a big issue, but required that > inheriting constructors call the "super" constructor on construction > (which isn't always desirable). For example, F (form) inherits from E, > but implements custom element and load methods. C (control) inherits > from E, but uses the stock methods. > > F = function(i, docNode) { > var el; > > if (this == global) { > return new F(i, docNode); > } > > // Custom element/load methods get and set the element > > function element() { > return el; > } > > this.load = function(name, docNode) { > el = typeof name == 'object' ? name : getForm(name, docNode); > this.element = (el)?element:null; > return this; > }; > > this.load(i, docNode); > }; > > C = function(i, docNode) { > > // Called without - new - operator > > if (this == global) { > return new C(i, docNode); > } > > // Uses stock E element/load methods > > E.call(this, i, docNode); > }; > > I'm no OO guru (or even fan), but I am happy with the way interface has > turned out. One nagging incongruity is that (as noted in the > documentation), you _must_ use the - new - operator when calling from > outside the frame containing the My Library script (sort of like dialing > the area code for a long-distance call). > > Functions are a bit more concise now too. The methods names are still > relatively verbose (which is not central to the issue IMO), but there > aren't as many calls to them now (which is what I consider the > determining factor for conciseness). Fewer calls makes for a lower > bill. ;) > > Your move, Andrea. Do your worst. :) Opera 10.10, Windows XP on a very busy and older PC:- 2121 18624 9000 5172 22248 4846 4360 1109 1266 1189 6140 1876 843* 798* I ran it a few times. This is representative. The two versions flip flop randomly. Usually around a third of the purer tests. :) The worst is always Prototype. Here roughly 30x slower than My Library. And it failed to return anything for one of the tests (undefined result). I remember that disqualification from the previous Operas as well (among other things). jQuery is at roughly 8X slower. The other three respectable scores were the two Dojo's and Qooxdoo. YUI3 came close to respectability. Of course, if you disallow all that sniff the UA string, the field shrinks considerably (down to four IIRC), retaining none of the noted respectable showings. If you do something wrong really fast, what are you accomplishing? I plan to add a column style to highlight that. Looking at results for the latest libraries in older (or odd) browsers shows without a doubt that the sniffing "strategies" failed miserably (and so can be predicted to fail miserably in the future).
From: Andrew Poulos on 15 Feb 2010 02:11 On 15/02/2010 3:45 PM, David Mark wrote: > I ran it a few times. This is representative. The two versions flip > flop randomly. Usually around a third of the purer tests. :) I'm not sure that if one person can write a library that's as good or better than libraries on which (I believe) teams of people have worked says a lot about one person's ability or not much about the others. I'm not meaning to be offensive, I'm just wondering how one person can appear to achieve so much. Andrew Poulos
From: Cody Haines on 15 Feb 2010 03:19 Andrew Poulos <ap_prog(a)hotmail.com> wrote: > On 15/02/2010 3:45 PM, David Mark wrote: > > I ran it a few times. This is representative. The two versions > > flip > > flop randomly. Usually around a third of the purer tests. :) > > I'm not sure that if one person can write a library that's as good or > better than libraries on which (I believe) teams of people have worked > says a lot about one person's ability or not much about the others. > Both. He's one of the best there is, and he's also the first one to tell you about how much the others suck. > I'm not meaning to be offensive, I'm just wondering how one person can > appear to achieve so much. I'm not sure if there was any way he could be offended there :) > > Andrew Poulos > P.S. I'm sending this from an iPhone app, so apologies if the formatting is screwy ~CH -- --Cody Haines
From: Michael Wojcik on 15 Feb 2010 11:56
Andrew Poulos wrote: > > I'm not meaning to be offensive, I'm just wondering how one person can > appear to achieve so much. Surely if studies of software development have taught us anything, they've taught us that there is no correlation between the size of a team and the quality of the code. I've been a professional developer for nearly a quarter of a century, and I'm not surprised at all when one person delivers a better solution than what a large team delivers. Even if the large team's total effort is much greater - which may or may not be the case here. Even if the large team has had ample opportunity to solicit feedback and review and improve their design and implementation. What matters more, in my opinion, are factors like understanding the problem space, employing a robust and consistent design, rigorous attention to quality, and preferring fewer well-implemented features to many poorly-implemented ones. An individual can often do better in those areas than a diverse and loosely-organized team can. That doesn't mean that the open-source "bazaar" development model necessarily produces bad code - just that it is vulnerable to sloppiness, uneven quality, and conflicting approaches. Sometimes that doesn't matter, if the project isn't meant to produce robust code. (Some projects are prototypes or toys.) Sometimes a strong editorial hand can enforce discipline on released code. But sometimes too many cooks simply spoil the soup. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University |