Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > TaskSpeed results for My Library

Reply
Thread Tools

TaskSpeed results for My Library

 
 
David Mark
Guest
Posts: n/a
 
      01-27-2010
TaskSpeed is another quasi-standard test that has never seen anything
like My Library. It was written by one of the Dojo guys. Yeah, I
know.

http://www.cinsoft.net/mylib-testspeed.html

It just flat-out murders the rest (even Dojo) And yes, the test
functions are _very_ concise (even too concise). And no, they aren't
even close to optimized. They even use the (optional) OO interface.
So there's really nothing left to argue as My Library is somehow
(much) faster _and_ more concise. Not to mention compatible with
virtually any agent, past, present or future.

So, what is it that caused whole armies of developers to write slow,
incompatible, brittle, browser sniffing BS for ten years? Would be
too slow and/or bloated if they didn't take the "pragmatic" (read
idiotic) approach? No doubt that everyone who listened to such
babbling got saddled with a lifetime installment plan of bad software
(now just upgrade to jQuery 1.6543 and everything just works again!)
and shelves lined with books describing just how awesome all of that
bad code really is. Now we have proof that it isn't.

Nobody ever needed any of it. In fact, they'd have been much better
off without it. Any company serious about Ajax development could have
developed something like My Library years ago and saved all of the
time of dealing with constant (and virtually mandatory) jQuery
upgrades, incompatibilies, inefficiency, etc. Not to mention all of
the time arguing if it was "better" than Prototype (or whatever). How
stupid (and/or ignorant) would you have to be to waste time and money
training to use one of these ever-changing monstrosities? Think how
many people need to be laid off now because all they know is jQuery
and Mootools.

As for companies that were not serious about browser scripting, they
should have left it alone. The users would never have missed a thing
(many would have preferred their sites without all of the Ajax-y
"goodness").

And where is this ExtCore thing? Nobody seems to have written a set
of tests for it. I may have to do it myself as I've seen the code and
am sure it will be slow and incompatible. Ext is another software
subscription service, except this one costs money AIUI. There will be
a full review of Ext (and a warning to steer clear of course) on
cinsoft.net soon Hard to believe people would buy into the idea of
paying a company to constantly fall flat on its face. I guess they've
convinced whatever customers they have left at this point that they
really are working on Mission Impossible (should just be a few more
years!). The various free libraries and frameworks have been feeding
the same line for years.

They are all working on some perfect solution to an impossible problem
and must continue working on it every day forever. Please bear with
them and continually download their code to "keep up" with the
browsers. Thing is, my scripts never fell behind, so I never knew
what they were going on about.

By the time the collective library authors learn ES and browser
scripting, there won't be any market for their wares. If that sounds
like an absurd situation, it is; but history has certainly seen
periods defined by absurdity and failure. Come to think of it, these
things fit right into the first decade of this century.

Oh, and I heard from Ajaxian (for those that care). They've decided
that since I said their site stinks (it does), they are not going to
report any news about My Library ever (picturing a child stamping
their feet). What a bunch of useless dip-shits. I bet they hang out
with JS library authors.
 
Reply With Quote
 
 
 
 
jdalton
Guest
Posts: n/a
 
      01-27-2010
Hi David,

I noticed a few problems with your tests.

1) You are comparing against older versions of some of the frameworks
which don't use querySelectorAll.
2) Your tests don't follow the standards of taskspeed. (You are
setting innerHTML properties instead of using the framework API where
available)
3) Your QSA adapter is too simple. QSA is buggy across almost all
browsers and you aren't addressing any of those issues.

Your framework fails in multiple modules, multiple browsers, and
multiple versions of browsers.
Your CSS selector engine is incomplete, slow (compared to current
engines) and fails to pass some basic unit tests of other frameworks.
What I find interesting is without complete/comprehensive tests you
claim superiority, but on a quick review one would find that your code
fails to pass the standards by which you judge other developers/
frameworks.
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 12:34 pm, jdalton <(E-Mail Removed)> wrote:
> Hi David,
>
> I noticed a few problems with your tests.


Oh good.

>
> 1) You are comparing against older versions of some of the frameworks
> which don't use querySelectorAll.


And comparing without it as well. See previous discussions. I am all
for testing the "slow lanes" as they are more significant IMO.

> 2) Your tests don't follow the standards of taskspeed.


What standard is that?

> (You are
> setting innerHTML properties instead of using the framework API where
> available)


I just put them up yesterday (and have been changing them to be more
OO to demonstrate how well those interfaces work). Here are the exact
tests that are up there now;-


"make" : function(){
var createAndAppend = API.createAndAppendElementWithAttributes;
var body = API.getBodyElement();
for (var i = 0; i < 250; i++) {
createAndAppend('ul', {'class':'fromcode', id:'setid' + i}, body,
document).innerHTML = '<li>one</li><li>two</li><li>three</li>';
}
return $('ul.fromcode').length;
},

"indexof" : function(){
var target = API.getEBI('setid150'), index = 0;
Q('ul').forEach(function() { index = this.indexOf(target); });
return index;
},

"bind" : function(){
return Q('ul > li').on('click', function(){}).length();
},

"attr" : function(){
return Q('ul').map(function(el) { return el.id }).length;
},

"bindattr" : function(){
var subscriber = function() {};
return Q('ul > li').on('mouseover', subscriber).setAttribute('rel',
'touched').off('mouseover', subscriber).length();
},

"table": function(){
var myTable = E(), myCell = E(), body = API.getBodyElement();
for (var i = 0; i < 40; i++) {
myTable.loadHtml('<table class="madetable"><tbody><tr><td>first</
td></tr></tbody></table>').appendTo(body);
myCell.loadNew('td').insertBefore(myTable.descenda nts('td')[0]);
}
return $('tr td').length;
},

"addanchor" : function(){
return Q('.fromcode > li').forEach(function(li){
li.innerHTML = '<a href="http://example.com">link</a>';
}).length();
},

"append" : function(){
var div, createAndAppend = API.createAndAppendElementWithAttributes,
doc = global.document, body = doc.body;
for (var i = 500; i-- {
createAndAppend('div', { 'rel':'foo2' }, body, doc);
}
return $("div[rel^=foo2]").length;
},

"addclass-odd" : function(){
return Q('div').addClass('added').filter(function(el, i) {
return (i % 2);
}).addClass('odd').length();
},

"style": function(){
return Q('.added').setStyles({
backgroundColor:'#ededed',
color: '#fff'
}).length();
},

"removeclass": function(){
return Q('.added').removeClass('added').length();
},

"sethtml": function(){
return Q('div').forEach(function(el) {
el.innerHTML = "<p>new content</p>";
}).load('div').length();
},

"insertbefore" : function(){
var myEl = E();
return Q('.fromcode a').forEach(function(a) {
myEl.loadNew('p').setText('A Link').insertBefore(a);
}).length();
},

"insertafter" : function(){
var myEl = E();
return Q('.fromcode a').forEach(function(a) {
myEl.loadNew('p').setText('A Link').insertAfter(a);
}).length();
},

"destroy": function(){
return Q('.fromcode').remove().length();
},

"finale": function(){
API.emptyNode(API.getBodyElement());
return $('body *').length;
}


I started to redo the last few that actually do touch the innerHTML
property. Like this:-

"make" : function(){
var myEl = E(), body = API.getBodyElement();
for (var i = 0; i < 250; i++) {
myEl.loadNew('ul', {'class':'fromcode', id:'setid' + i}).setHtml
('<li>one</li><li>two</li><li>three</li>').appendTo(body);
}
return $('ul.fromcode').length;
},

....which is slightly slower. But nothing can bridge the exponential
gap between My Library and the rest.

There's only two other tests that use any DOM property (e.g.
innerHTML). Both are near identical:-

"sethtml": function(){
return Q('div').forEach(function(el) {
el.innerHTML = "<p>new content</p>";
}).load('div').length();
},

"addanchor" : function(){
return Q('.fromcode > li').forEach(function(li){
li.innerHTML = '<a href="http://example.com">link</a>';
}).length();
},

Solution is obvious:-

"sethtml": function(){
return Q('div').setHtml('<p>new content</p>').load('div').length();
},

Six of one, half a dozen of the other. Might slow it down a hair, but
then changing to use DOM appends might speed it back up. Who knows?
It won't make the others any faster, that's for sure. And yes,
several of them use "cheating" like innerHTML as well:-

"make" : function(){
var ul;
for ( var i = 0; i < 250; i++ ) {
ul = document.createElement('ul');
YAHOO.util.Dom.addClass(ul, 'fromcode');
YAHOO.util.Dom.setAttribute(ul, 'id', 'setid'+i);
document.body.appendChild(ul);
ul.innerHTML = '<li>one</li><li>two</li><li>three</li>';
}
return YAHOO.util.Selector.query('ul.fromcode').length;
},



> 3) Your QSA adapter is too simple. QSA is buggy across almost all
> browsers and you aren't addressing any of those issues.


Well, it is only a day old. How much do you want to bet I can make it
bypass buggy selectors without resorting to browser sniffing and
without needlessly slowing down the "fast lane?" Who else is better
qualified to do that? And who told those other nimrods to dump QSA
into their core? It's a mistake.

>
> Your framework fails in multiple modules, multiple browsers, and
> multiple versions of browsers.


Care to elaborate on any of that? Sounds like the opposite of what
the documented testing has uncovered. And yes, automated unit testing
will follow. The difference is that I won't be surprised by wrong
results and I won't allow such results to shape my design.

> Your CSS selector engine is incomplete, slow (compared to current
> engines) and fails to pass some basic unit tests of other frameworks.


I never said it covered every selector. It is hardly slow (as the
tests have shown). I am sure it fails to pass unit tests involving
selectors it doesn't support. Read the instructions before testing.
It's faster than virtually everything on virtually everything. And so
what? I never told you to use a CSS selector query engine. It's just
stupid.

> What I find interesting is without complete/comprehensive tests you
> claim superiority, but on a quick review one would find that your code
> fails to pass the standards by which you judge other developers/
> frameworks.


No, you just have no idea what you are talking about. For instance,
there's a big difference between eschewing a few selector types (which
are documented) and completely failing to understand how - for example
- IE works (while releasing script after script claiming to solve it
for good!) If it's been ten years and you still read documents
(or measure elements) wrong in IE, you aren't qualified to solve cross-
browser problems for the rest of us.

The whole point is that you do not need an army of code monkeys
rewriting the same script, year after year, adding more bloat and
complexity, requiring re-testing, deprecating "old" browsers, etc.
It's been a complete waste of time as it lead up to a bunch of slow,
buggy "standard" renditions that are virtually unusable on the Web.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 12:34 pm, jdalton <(E-Mail Removed)> wrote:
> Hi David,
>


Hi, "jdalton". I thought I recognized that moniker. Prototype
hawker, huh? That library should never have been written. It manages
to be the slowest (at virtually anything) while also throwing bizarre
exceptions in anything but the latest browsers (and some of the latest
too). And it isn't for real. It's just a collection of browser
observations made by people with no idea what they were observing. It
won't (doesn't) hold up. That's why a million monkeys keep churning
out new Prototypes. Stop and look at the design (from a neophyte in
2005) and realize it will never be competent.

Now, can you you accuse My Library of that?
 
Reply With Quote
 
jdalton
Guest
Posts: n/a
 
      01-27-2010
Hi David,

Taskspeed is standardized by Peter Higgins, he ensures that no one lib
is taking shortcuts or misrepresenting their framework.
If you really want your Taskspeed tests considered lagit, fork his,
add it, and send him a pull request.
If you take issue with one or more of the tests you can correct it and
send him a pull request.

Please correct me if I am wrong on this.
When I or others find flaws in your work it's not a knock against you
or your framework in fact you did it, whatever the flaw is, by design.
On the other hand when you find faults in others code/frameworks/
libraries they are labeled incompetent.

As for unit tests (massive fails):

(failing Prototype tests)
http://dl.dropbox.com/u/513327/mylib...prototype.html

(failing jQuery tests, commented out the jq custom selector tests)
http://dl.dropbox.com/u/513327/mylib/test/jquery1.html
http://dl.dropbox.com/u/513327/mylib/test/jquery2.html (wont even run
the tests some bug in mylib)

(failing Dojo, Yahoo, Closure, and other tests)
http://dl.dropbox.com/u/513327/mylib/test/slick.html

(simple Slickspeed that works with your limited set of selectors
showing it as one of the slowest)
http://dl.dropbox.com/u/513327/mylib...eed/index.html


> Well, it is only a day old.

You are promoting it as if its the best thing around (on twitter, your
google group, and clj)

> How much do you want to bet I can make it bypass buggy selectors ...

Then you will join the rest who have without sniffing. I don't doubt
your ability.
Random thought, have you tried submitting bug reports against the
frameworks you flame ?

> I never said it covered every selector.

Others cover more selectors/bugs which can add to complexity and drain
overall performance.

> I never told you to use a CSS selector query engine.
> It's just stupid.

You are the one showing Slickspeed results and promoting your
framework as faster/better.

> Prototype hawker, huh?

I haven't contributed or endorsed Prototype for some time now.


 
Reply With Quote
 
Scott Sauyet
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 12:09 pm, David Mark <(E-Mail Removed)> wrote:
> TaskSpeed is another quasi-standard test that has never seen anything
> like My Library. It was written by one of the Dojo guys. Yeah, I
> know.
>
> http://www.cinsoft.net/mylib-testspeed.html
>
> It just flat-out murders the rest (even Dojo) And yes, the test
> functions are _very_ concise (even too concise). And no, they aren't
> even close to optimized. They even use the (optional) OO interface.
> So there's really nothing left to argue as My Library is somehow
> (much) faster _and_ more concise. Not to mention compatible with
> virtually any agent, past, present or future.


My results don't agree. I've posted another version, which restricts
the comparison to the latest versions of the libraries from your list,
upgrading to the latest version of jQuery and MooTools. (I couldn't
find test files for more recent versions of YUI or qooxdoo; the others
were already at the latest, I believe.) I ran the tests on a modern
Windows XP SP2 machine with dual 3.0GHz CPUs and 3.25 GB of RAM.

While My Library here performs well, it's far from murdering the
competition.

My tests are at:

http://scott.sauyet.com/Javascript/T...d/2010-01-27a/

My results are here:

http://scott.sauyet.com/Javascript/T...1-27a/results/

I will duplicate those results as an ASCII table below.

Among the seven libraries tested, my results rank My Library as second
fastest in Chrome, third in Firefox, fourth in IE, second in Opera,
and first in Safari (here beating even the "Pure DOM" solution by over
30%!) These are good results, no doubt, but not a runaway win. If
any library can claim to be fastest from my tests, it's definitely
qooxdoo, which was the fastest in four of the five browsers, and
outperformed the "Pure Dom" tests in three of them.

I first tried testing against a version of My Library that I
downloaded January 22. Many of the tests failed. Has the API changed
so drastically in the last few days?

-- Scott


Results (ASCII table, useful mainly with fixed-width font)
================================================== ========

Browsers:
---------
Chrome 3.0.195.27
Firefox 3.5.7
IE 8
Opera 9.64
Safari 4.0.3

+--------+--------+--------+--------+--------+
| Chrome | Firefox| IE | Opera | Safari |
+-------------------+--------+--------+--------+--------+--------+
| Pure Dom | 206 | 290 | 906 | 219 | 224 |
+-------------------+--------+--------+--------+--------+--------+
| Dojo 1.4.0 | 225 | 428 | 2018 | 309 | 202 |
+-------------------+--------+--------+--------+--------+--------+
| jQuery 1.4.0 | 458 | 937 | 2922 | 484 | 388 |
+-------------------+--------+--------+--------+--------+--------+
| MooTools 1.2.4 | 304 | 851 | 5686 | 642 | 244 |
+-------------------+--------+--------+--------+--------+--------+
| Prototype 1.6.0.3 | 405 | 1105 | 4529 | 920 | 353 |
+-------------------+--------+--------+--------+--------+--------+
| qooxdoo 0.8.2 | 160 | 406 | 1593 | 217 | 218 |
+-------------------+--------+--------+--------+--------+--------+
| YUI 2.7.0 | 299 | 866 | 2172 | 439 | 317 |
+-------------------+--------+--------+--------+--------+--------+
| My Library (QSA) | 167 | 447 | 2642 | 269 | 155 |
+-------------------+--------+--------+--------+--------+--------+

 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 2:32 pm, jdalton <(E-Mail Removed)> wrote:
> Hi David,
>
> Taskspeed is standardized by Peter Higgins, he ensures that no one lib
> is taking shortcuts or misrepresenting their framework.


Standardized is a strong word, but okay. What happened with - for
example - YUI's tests?

> If you really want your Taskspeed tests considered lagit, fork his,


I downloaded his, so it would be lagit (sic).

> add it, and send him a pull request.


A what request? Do you mean that thing that sends back results? It
doesn't work as it tries to download Dojo via a SCRIPT element, sets
onreadystatechange, and... oh never mind.

> If you take issue with one or more of the tests you can correct it and
> send him a pull request.


What does any of this mean? If I have an "issue" with the test, I
rewrite it. I just rewrote three of mine to remove the innerHTML
property access. Whatever. Still kills the rest (as you will see in
a moment).

>
> Please correct me if I am wrong on this.


On what?

> When I or others find flaws in your work it's not a knock against you
> or your framework in fact you did it, whatever the flaw is, by design.


You haven't found **** so far as I can see. You babbled a few
generalizations, but didn't really say anything specific about any of
them. See the My Library forum for lessons on how to test and report
(as well as how I react to such "criticism").

> On the other hand when you find faults in others code/frameworks/
> libraries they are labeled incompetent.


No, you are oversimplifying at best. They _are_ incompetent. I can
tell that from their _code_. I don't need to test any of their
bullshit at all. And when you are tearing up and rewriting browser
sniffs (and other misconceived code) every month to "keep" up with
some imagined opponent, you have to stop and think "I am incompetent",
right? If not, there's another word: insane.

>
> As for unit tests (massive fails):
>
> (failing Prototype tests)http://dl.dropbox.com/u/513327/mylib...prototype.html
>
> (failing jQuery tests, commented out the jq custom selector tests)http://dl.dropbox.com/u/513327/mylib...ery2.html(wont even run
> the tests some bug in mylib)
>
> (failing Dojo, Yahoo, Closure, and other tests)http://dl.dropbox.com/u/513327/mylib/test/slick.html
>
> (simple Slickspeed that works with your limited set of selectors
> showing it as one of the slowest)http://dl.dropbox.com/u/513327/mylib...eed/index.html
>
> > Well, it is only a day old.

>
> You are promoting it as if its the best thing around (on twitter, your
> google group, and clj)


You really aren't paying attention are you.

1. Rushing to put QSA on top of broken, inconsistent DOM traversal is
STUPID.
2. That's what they all did.

Mine is an add-on and it really isn't needed at all (as the original
tests showed). It helps to sway the deluded though (other than the
irretrievably stupid ones).

>
> > How much do you want to bet I can make it bypass buggy selectors ...

>
> Then you will join the rest who have without sniffing.


Who would that be? If they used feature testing, where do you think
they _got_ those techniques.

> I don't doubt
> your ability.


That's nice.

> Random thought, have you tried submitting bug reports against the
> frameworks you flame ?


Random thought, there's no hope for them, regardless of how many times
they are patched. There's an incompetence-imposed ceiling. You do
realize I _rewrote_ Dojo/Dijit/DojoX in its _entirety_ at one point
(as well as gave Resig solutions to various problems that he still
hasn't solved). And I don't "flame" anybody. It's not my fault if
people are deluded, or overconfident or stupid or whatever. I just
bring these issues to light by reviewing their "work".

>
> > I never said it covered every selector.

>
> Others cover more selectors/bugs which can add to complexity and drain
> overall performance.


Uh, no. You clearly don't understand how they work. The (4 or 5)
missing selectors are just extra switch cases. They won't add any
time to the other selectors. Nice try though.

And none of it is complicated (*= and |= are as simple as ^= and the
like). Sorry. The whole selector engine is like a homework
assignment for a first-year CS student. If a million monkeys can't
get it right after years of pounding on their keyboards and peering at
unit tests (and nobody really needs it anyway)... well, you figure it
out.

>
> > I never told you to use a CSS selector query engine.
> > It's just stupid.

>
> You are the one showing Slickspeed results and promoting your
> framework as faster/better.


No, you've got this all screwed up. I put that page up there _two
years ago_. I've barely said a thing about it since. Then some other
guy came along (here) and asked about speed tests. I pointed him to
that page and he ran with it (straight into a brick wall I might
add). I certainly find the TaskSpeed results more interesting. But,
the thing is, I knew all along mine was faster at virtually everything
on virtually everything. I've seen the code.

>
> > Prototype hawker, huh?

>
> I haven't contributed or endorsed Prototype for some time now.


LOL. Moved on to jQuery?
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 2:32 pm, jdalton <(E-Mail Removed)> wrote:
> Hi David,
>
> Taskspeed is standardized by Peter Higgins, he ensures that no one lib
> is taking shortcuts or misrepresenting their framework.
> If you really want your Taskspeed tests considered lagit, fork his,
> add it, and send him a pull request.
> If you take issue with one or more of the tests you can correct it and
> send him a pull request.
>
> Please correct me if I am wrong on this.
> When I or others find flaws in your work it's not a knock against you
> or your framework in fact you did it, whatever the flaw is, by design.
> On the other hand when you find faults in others code/frameworks/
> libraries they are labeled incompetent.
>
> As for unit tests (massive fails):
>
> (failing Prototype tests)http://dl.dropbox.com/u/513327/mylib...prototype.html
>
> (failing jQuery tests, commented out the jq custom selector tests)http://dl.dropbox.com/u/513327/mylib....html(wonteven run
> the tests some bug in mylib)


My Library won't run jQuery's unit tests and you consider this to be a
bug in My Library? Pardon me if I ignore the rest of your
reports.

>
> (failing Dojo, Yahoo, Closure, and other tests)http://dl.dropbox.com/u/513327/mylib/test/slick.html
>
> (simple Slickspeed that works with your limited set of selectors
> showing it as one of the slowest)http://dl.dropbox.com/u/513327/mylib...eed/index.html


Why would you have to reproduce that page? There's already a page on
cinsoft.net that runs the "limited" (40 - 4 or so IIRC) selectors.
Any result that shows it as one of the "slowest" is clearly suspect.
I can tell you that without looking at any of your results (I've seen
all of the code).
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 3:20 pm, Scott Sauyet <(E-Mail Removed)> wrote:
> On Jan 27, 12:09 pm, David Mark <(E-Mail Removed)> wrote:
>
> > TaskSpeed is another quasi-standard test that has never seen anything
> > like My Library. It was written by one of the Dojo guys. Yeah, I
> > know.

>
> >http://www.cinsoft.net/mylib-testspeed.html

>
> > It just flat-out murders the rest (even Dojo) And yes, the test
> > functions are _very_ concise (even too concise). And no, they aren't
> > even close to optimized. They even use the (optional) OO interface.
> > So there's really nothing left to argue as My Library is somehow
> > (much) faster _and_ more concise. Not to mention compatible with
> > virtually any agent, past, present or future.

>
> My results don't agree. I've posted another version, which restricts
> the comparison to the latest versions of the libraries from your list,


My list?! It's the TaskSpeed suite downloaded from Higgins' site.

> upgrading to the latest version of jQuery and MooTools. (I couldn't
> find test files for more recent versions of YUI or qooxdoo; the others
> were already at the latest, I believe.)


Great. I added YUI3 to mine. It's slower than the previous YUI (of
course).

> I ran the tests on a modern
> Windows XP SP2 machine with dual 3.0GHz CPUs and 3.25 GB of RAM.


Okay.

>
> While My Library here performs well, it's far from murdering the
> competition.


I'll be sure and run them through the gamut... And you have to look
at it as a whole (tested across a wide set of agents):-

1. Much faster
2. Compatibility with more than just the lastest browsers
3. Comparitively smaller
4. No dubious plug-ins to download (and download and download...)

5. Last (but hardly least), not full of browser sniffs and other
incompetent nonsense (see jQuery discussions going back for years).

>
> My tests are at:
>
> http://scott.sauyet.com/Javascript/T...d/2010-01-27a/
>


I will definitely try them out. I assume you used the version with
the QSA add-on.

> My results are here:
>
> http://scott.sauyet.com/Javascript/T...1-27a/results/
>
> I will duplicate those results as an ASCII table below.


Thanks!

>
> Among the seven libraries tested, my results rank My Library as second
> fastest in Chrome, third in Firefox, fourth in IE, second in Opera,
> and first in Safari (here beating even the "Pure DOM" solution by over
> 30%!) These are good results, no doubt, but not a runaway win.


Well, they are just one set of results on one machine. We test lots
of machines and look at the aggregate picture, considering slower,
older and limited agents, as well as the current run-of-the-mill
Windows installation.

But, lets break the results down. Chrome is really a photo finish
between Qooxdoo and My Library (7ms difference). So call that a tie
for first. On slower machines, phones, etc. My Library kills ooxdoo
(how do you even pronounce that?) Same in newest FF (looks like a
three-way tie). On older FF's, My Library is exponentially faster
than all of them. Looking ahead, there's really not much to recommend
any of the (buggy as hell) others over My Library. They'd have to
demonstrate massive speed advantages to overcome all of the other
inherent objections.


If
> any library can claim to be fastest from my tests, it's definitely
> qooxdoo, which was the fastest in four of the five browsers, and
> outperformed the "Pure Dom" tests in three of them.


You are putting way too much stock into one test run.

>
> I first tried testing against a version of My Library that I
> downloaded January 22. Many of the tests failed.
> Has the API changed
> so drastically in the last few days?


Per user requests, I added some new selectors. I also added some new
syntactic sugar to the (optional) OO interface so that nobody would
cry foul about "cheating" with "pure" DOm methods. That's what you
are seeing. The core API is unmoved (most of it for years).

>
> -- Scott
>
> Results (ASCII table, useful mainly with fixed-width font)
> ================================================== ========
>
> Browsers:
> ---------
> Chrome 3.0.195.27
> Firefox 3.5.7
> IE 8
> Opera 9.64
> Safari 4.0.3
>
> +--------+--------+--------+--------+--------+
> | Chrome | Firefox| IE | Opera | Safari |
> +-------------------+--------+--------+--------+--------+--------+
> | Pure Dom | 206 | 290 | 906 | 219 | 224 |
> +-------------------+--------+--------+--------+--------+--------+
> | Dojo 1.4.0 | 225 | 428 | 2018 | 309 | 202 |
> +-------------------+--------+--------+--------+--------+--------+
> | jQuery 1.4.0 | 458 | 937 | 2922 | 484 | 388 |
> +-------------------+--------+--------+--------+--------+--------+
> | MooTools 1.2.4 | 304 | 851 | 5686 | 642 | 244 |
> +-------------------+--------+--------+--------+--------+--------+
> | Prototype 1.6.0.3 | 405 | 1105 | 4529 | 920 | 353 |
> +-------------------+--------+--------+--------+--------+--------+
> | qooxdoo 0.8.2 | 160 | 406 | 1593 | 217 | 218 |
> +-------------------+--------+--------+--------+--------+--------+
> | YUI 2.7.0 | 299 | 866 | 2172 | 439 | 317 |
> +-------------------+--------+--------+--------+--------+--------+
> | My Library (QSA) | 167 | 447 | 2642 | 269 | 155 |
> +-------------------+--------+--------+--------+--------+--------+


YUI 2.7? I thought you were using the latest stuff? See mine. I
just added YUI3 (waste of time though).
 
Reply With Quote
 
Scott Sauyet
Guest
Posts: n/a
 
      01-27-2010
On Jan 27, 12:09*pm, David Mark <(E-Mail Removed)> wrote:
> TaskSpeed is another quasi-standard test that has never seen anything
> like My Library. *


I think one of your tests is incomplete.

The test indexOf is documented like this:

"indexof" : function(){
// in a 20-iteration for loop:
// find the node with id="setid150"
// find all the ul's in the DOM
// locate the index of the found node in the list of nodes
// return that index
}

but your implementation (as of a few minutes ago, at least, skips the
20-iteration loop:

"indexof" : function(){
var target = API.getEBI('setid150'), index = 0;
Q('ul').forEach(function() { index = this.indexOf(target); });
return index;
},

I can't imagine it make too much of a difference in the overall
results, but it's probably worth fixing sooner rather than later.

-- Scott

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
My Library _passes_ TaskSpeed in IE < 7 David Mark Javascript 88 03-07-2010 01:18 AM
My Library TaskSpeed tests updated David Mark Javascript 31 02-23-2010 08:08 PM
How can I make this more efficient? (combining DataSet results with the results of a DB lookup.) Ken Fine ASP .Net 3 07-23-2008 08:11 AM
Prefix increment/decrement results in lvalue, but postfix one results in rvalue? lovecreatesbeauty C++ 8 09-12-2005 10:23 PM
Displaying results as "pages" of a JTable and sorting across all results ... Monique Y. Mudama Java 1 06-28-2005 01:01 AM



Advertisments