TaskSpeed results for My Library

[David Mark]

And Finally:http://debuggable.com/posts/rightjs-1-5-6-8-times-faster-than-jquery:...

With explanation about PureDOM, a proper cheat via innerHTML (did not
spend too much to create it tho) and the reason this thread is
pointless, imho.

I'd say your contributions have been pointless so far. Yes, you
should make the "baseline" as fast as possible without sacrificing
cross-browser compatibility.

 

[David Mark]

I posted my results earlier in the thread:

   http://scott.sauyet.com/Javascript/Test/taskspeed/2010-01-27a/results/

Dojo outperformed it in Safari, qooxdoo did in Chrome, Opera, and
Safari, and My Library did in Chrome and Safari.  None of the speed
differences were huge.

They are on older PC's (and mobile devices). 60% faster in Chrome/
Safari on an older (but not ancient) XP box. Lots of "normal people"
have such equipment, of course.

 

[David Mark]

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.

 

[David Mark]

[...]

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).

 

[jdalton]

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.

 

[David Mark]

Hi David,


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?

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.

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.

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

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.

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.

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".

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!

Again, you are missing several basic bug fixes/browser issues because
you refuse to look at others tests.

Again, see above.

 

[David Mark]

[...]

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.

 

[jdalton]

Hi David,

http://en.wikipedia.org/wiki/Denial
"Denial is a defense mechanism postulated by Sigmund Freud, in which a
person is faced with a fact that is too uncomfortable to accept and
rejects it instead, insisting that it is not true despite what may be
overwhelming evidence."

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.

Denial (bugs were not related to multiple identical IDs)

You aren't following (and are clearly out of that loop). Denial

See above. What you see as a bug may not be a bug at all.

True, I have stated some may not be bugs, but a lot are valid bugs in
your code.

That's a completely worthless statement. Denial

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). Denial

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.

Denial, majority of your posts are rants and you reply to yourself
regularly in your g-group (alias optional).

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.

Classic David Mark

Another worthless generalization. All things relative, it's far more
solid than anything out there. Denial

You really are a disingenuous idiot.

Classic David Mark

I should try a modified version of SlickSpeed? Why?

Because 0ms results are almost worthless. It's better to see how many
executions can happen in a given time period.

According to whatever nonsensical theory you have come up with about
CSS selector engines (which are a stupid idea to begin with).

Your approach is slow, so of course, the entire idea it's based on has
to be stupid. Classic David Mark.

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

Pot calling kettle. Your spamming, ranting, and harassment has reached
new levels since you were relieved from SitePen.

 

[David Mark]

[...]

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/

Hell, why not?

FF1:-

12 14 9 11* 33 17 9

*Mine


Chrome:-

90 155 48 28* 646 252 160

*Mine

Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your
language?

And, of course, these tests must be run multiple times in a variety of
environments to indicate anything of substance. Still, it sure
doesn't look like "one of the slowest" from the early returns.

 

[jdalton]

Hi David,

Heh,
You have it backwards (larger number is better),
smaller is worse, that means your methods executed slower than anyone
else.
Congratulations.

 

[David Mark]

Hi David,

http://en.wikipedia.org/wiki/Denial
"Denial is a defense mechanism postulated by Sigmund Freud, in which a
person is faced with a fact that is too uncomfortable to accept and
rejects it instead, insisting that it is not true despite what may be
overwhelming evidence."

Uh, thanks for that.

Denial (bugs were not related to multiple identical IDs)

I addressed all of your reported "bugs" in another post in this thread.
Anything else?

Denial

Repeating it doesn't make it true.

True, I have stated some may not be bugs, but a lot are valid bugs in
your code.

Could be. All things relative, it is not a termite farm like the
others.

Denial

See above.

Sheesh.


Denial, majority of your posts are rants and you reply to yourself
regularly in your g-group (alias optional).

I certainly do not. I slipped up and posted with my
anti-Google-posting-limit alias once or twice. So what?

Classic David Mark

See what I mean?

Denial

A broken record.

Classic David Mark

See above. You really are my #1 fan, aren't you?

Because 0ms results are almost worthless. It's better to see how many
executions can happen in a given time period.

And I tried your tests and the results were predictable (mine is not
even close to "one of the slowest.") What were you testing?

Your approach is slow, so of course, the entire idea it's based on has
to be stupid. Classic David Mark.

My approach is _not_ slow. In contrast, it is blazing fast compared to
the "majors" in some environements and comparable in others. You just
make this stuff up as you go along? Saying "it's slow" over and over in
the face of overwhelming evidence to the contrary is silly.

Pot calling kettle. Your spamming, ranting, and harassment has reached
new levels since you were relieved from SitePen.

You are just full of misconceptions.

And don't expect a "jdalton" tribute page any time soon.

 

[David Mark]

Hi David,

This is a newsgroup. And what are you replying to?

Heh,
You have it backwards (larger number is better),

According to you. I have reason to doubt the veracity of your tests,
especially if QSA is involved. All of the other incarnations of
SlickSpeed are BS, but yours is gold? I doubt it.

smaller is worse, that means your methods executed slower than anyone
else.

But, assuming your tests make sense, that isn't what the data indicated
at all, is it? I would highlight that if you had bothered to quote me.

 

[S.T.]

Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your
language?

It's testing ops/ms, so... yeah... bigger numbers are better. The "final
ops/ms (more is better)" label in the final results is a big giveaway.

And, of course, these tests must be run multiple times in a variety of
environments to indicate anything of substance. Still, it sure
doesn't look like "one of the slowest" from the early returns.

OK. Here's my results.

On IE6 yours fairs alright. Behind JQuery/Sizzle and NWMatcher, but
ahead of the others. Pretty close top-to-bottom here.
58 99 42 78* 126 114 47

On Win/Chrome 4.0.249.78 yours is dead last, a little behind Mootools
and Dojo, with the others well ahead.
517 1298 246 162* 2926 1780 1357

On Wn/FF3.6 dead last again, not far behind Mootools at least.
374 435 279 141* 1386 526 458

On IE8 you beat Mootools handily, behind to well-behind the rest.
209 435 64 143* 811 533 476

 

[David Mark]

It's testing ops/ms, so... yeah... bigger numbers are better. The "final
ops/ms (more is better)" label in the final results is a big giveaway.

If I had bothered to pay attention to his folly, I would have seen that.
So what?

And who knows what it is testing? Have you looked at the code? Do you
really think there is such a measurable difference between QSA calls? I
don't.

OK. Here's my results.

On IE6 yours fairs alright. Behind JQuery/Sizzle and NWMatcher, but
ahead of the others. Pretty close top-to-bottom here.
58 99 42 78* 126 114 47

On that run. See above.

On Win/Chrome 4.0.249.78 yours is dead last, a little behind Mootools
and Dojo, with the others well ahead.
517 1298 246 162* 2926 1780 1357

Whatever that means. See above.

On Wn/FF3.6 dead last again, not far behind Mootools at least.
374 435 279 141* 1386 526 458

On IE8 you beat Mootools handily, behind to well-behind the rest.
209 435 64 143* 811 533 476

Again. What makes you think these numbers have any meaning at all?
because "jdalton" said they did?

 

[gf3]

If I had bothered to pay attention to his folly, I would have seen that.
 So what?

And who knows what it is testing?  Have you looked at the code?  Do you
really think there is such a measurable difference between QSA calls?  I
don't.






On that run.  See above.




Whatever that means.  See above.





Again.  What makes you think these numbers have any meaning at all?
because "jdalton" said they did?

WebKit Nightly Version 4.0.4 (6531.21.10, r54448)

834 1317 361 189* 2694 1934 1495

Jussayin'

 

[David Mark]

WebKit Nightly Version 4.0.4 (6531.21.10, r54448)

834 1317 361 189* 2694 1934 1495

Great! Now if someone can explain why these numbers have any meaning at
all... Otherwise, they are just numbers.

My QSA wrapper is so thin that it makes me think these tests are bogus
or he used my QSA-less version. I don't have the interest to
investigate, but perhaps somebody else will.

 

[AlexSexton]

WebKit Nightly Version 4.0.4 (6531.21.10, r54448)

 834     1317    361     189*    2694    1934    1495

Jussayin'

MyLibrary in my tests:

latest Chrome (5.0.317.2)/Vista-x64
592 1290 296 202* 3276 1796 1403

Firefox 3.6
321 395 269 149* 1260 458 419

IE8:
193 383 58 128* 708 479 404

Hell, I'll set up a jdalton tribute site if it makes David Mark wrong
(again)...

 

[David Mark]

Great! Now if someone can explain why these numbers have any meaning at
all... Otherwise, they are just numbers.

My QSA wrapper is so thin that it makes me think these tests are bogus
or he used my QSA-less version. I don't have the interest to
investigate, but perhaps somebody else will.

This is it:-

// QSA add-on uses built-in queries
var global = this;
if (this.API && this.API.getEBCS && this.API.isHostMethod(this.document,
'querySelectorAll')) {
(function() {
var oldGetEBCS = this.API.getEBCS;
var toArray;

try {
(Array.prototype.slice.call(global.document.querySelectorAll('html'),
0));
toArray = function(a) {
return Array.prototype.slice.call(a, 0);
};
} catch(e) {
toArray = API.toArray;
}

this.API.getEBCS = function(s, d) {
try {
return toArray((d || global.document).querySelectorAll(s));
} catch(e) {
return oldGetEBCS(s, d);
}
};
if (typeof $ == 'function') {
$ = this.API.getEBCS;
}
})();
}

Other than the try-catch, I don't see anything between the script and
the browser's built-in queries. The toArray function will be like
lightning in the tested browsers (excluding IE) as well. So what can
these numbers possibly indicate (aside from the fact that "jdalton"
considers them more "accurate" than the original SlickSpeed tests). I
predict it is all a waste of time.

Meanwhile, jQuery still can't read (documents) and "jdalton" is making a
fool of himself on Twitter. There's progress.

 

[David Mark]

MyLibrary in my tests:

latest Chrome (5.0.317.2)/Vista-x64
592 1290 296 202* 3276 1796 1403

Firefox 3.6
321 395 269 149* 1260 458 419

IE8:
193 383 58 128* 708 479 404

Hell, I'll set up a jdalton tribute site if it makes David Mark wrong
(again)...

That's what all of this comes down to? Proving me "wrong?" LOL.

Amazing how the losers come out of the woodwork when they think they've
found an in. What do these numbers mean to you, other than they somehow
prove that I am "wrong?"

 

[jdalton]

Hi David,

The QSA add-on is not needed as
the library is certainly fast enough without it.

You said yourself your QSA add-on isn't needed you also don't have it
as an option in your build system (or I couldn't find it)

Other than the try-catch, I don't see anything between the script and
the browser's built-in queries.

That's a problem because QSA is buggy across all browsers and you
don't attempt to fix anything. Also many of these selector engines
bypass QSA, for simple queries, altogether.

Here are test results not effected by QSA

IE 7.0.5730.11
32 51 21 39* 73 59 26

IE 6.0.2900.5122.xpsp_sp3.gdr.080814-1236
30 50 20 38* 75 59 26

IE 8.0.6001.18702 (Compatibility View)
56 91 33 72* 216 108 62

Opera 9.50 (build 10063)
160 150 55 *68 339 170 128