TaskSpeed results for My Library

D

David Mark

AlexSexton said:
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)...

Make sure you mention he's a squirrelly, obsessed cheater. :)

1. As I suspected, he is comparing their QSA with my stock library
(without the QSA add-on). Duh, of course that will make a difference in
these tests. Don't see how that proves me "wrong" about anything
though. Proves him disingenuous (and foolhardy) for sure. ;)

2. He's got an (obviously unneeded) extra dot operation in each call to
mine. Sabotage or stupidity, it really doesn't matter.

This guy has all the credibility of... hell, I can't think of anyone
less credible. VK? Why would anyone go to this much trouble to look
like an idiot?

I wonder how many more losers will show up to celebrate this great
"victory" for incompetence over understanding?

Also, the build he used is 32K _before_ minification, so that supports
the conciseness angle. I suppose I should use such a build on my site
to eliminate confusion about file sizes.

In any event, this is hardly science. ;)
 
D

David Mark

jdalton said:
Hi David,

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)

I know what I said and I stand by it. It isn't needed at all. The
"standard" TaskSpeed tests bear this out as they are closer to
approximating what an application will do. Your version of SlickSpeed
is obviously going to be affected, but who cares?
That's a problem because QSA is buggy across all browsers and you
don't attempt to fix anything.

So? Of course, it still passes all of these tests. I'll deal with
feature testing QSA when I get around to it. As I've mentioned, QSA
isn't needed. And adding one-off feature tests won't affect any of the
speed tests cited so far as they already _pass_ (so there will be no
bypass).

And are you really congratulating the "majors" for stacking one
patchwork on top of another? Does that make any sense at all? I know
it makes sense to them as they think they have to "keep up" with each
other. The reality is that each layer is full of bugs, particularly the
ones they've been working on non-stop for years (DOM traversal and
XPath). Now they are off on another tangent. How does that help
anything but their egos? Users don't really care (or know) about speed
tests.

Also many of these selector engines
bypass QSA, for simple queries, altogether.

Yes, they call gEBI, gEBTN, etc., just as I do in the "slow lane".
What's your point?
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

Interesting you went with an (almost) all-IE line-up this time. More
chicanery? And don't talk to me about IE compatibility view. None of
the others came close to working in IE8's various modes and they spent
months working with the Beta versions, twiddling their browser sniffing,
etc. In contrast, I did _nothing_ and was pleasantly surprised when
_everything_ still worked on first load in IE8. ;)
Opera 9.50 (build 10063)
160 150 55 *68 339 170 128

Looks pretty inconclusive (not to mention spotty) now. So much for your
"more accurate" tests. ;)

Where's Webkit?
 
G

gf3

Make sure you mention he's a squirrelly, obsessed cheater.  :)

1. As I suspected, he is comparing their QSA with my stock library
(without the QSA add-on).  Duh, of course that will make a difference in
these tests.  Don't see how that proves me "wrong" about anything
though.  Proves him disingenuous (and foolhardy) for sure.  ;)

2. He's got an (obviously unneeded) extra dot operation in each call to
mine.  Sabotage or stupidity, it really doesn't matter.

This guy has all the credibility of...  hell, I can't think of anyone
less credible.  VK?  Why would anyone go to this much trouble to look
like an idiot?

I wonder how many more losers will show up to celebrate this great
"victory" for incompetence over understanding?

Also, the build he used is 32K _before_ minification, so that supports
the conciseness angle.  I suppose I should use such a build on my site
to eliminate confusion about file sizes.

In any event, this is hardly science.  ;)

Well, at least you're humble.
 
D

David Mark

gf3 wrote:

[...]
Well, at least you're humble.

You seemed to have missed something as that response makes no sense in
context. And get a real name. Who is going to listen to initials?
 
D

David Mark

David Mark wrote:

[...]
"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. ;)

And furthermore, if he bothered to pay attention here, he would know
that I frequently ridicule the "majors" for jumping through hoops to
"normalize" the height/width of elements that are not part of the
layout. Hint: elements that are not part of the layout have no
height/width (or can be considered 0,0). So once again, "jdalton" has
identified a non-bug. He's showing his roots as most of these are the
sorts of things Prototype wasted time on over the years, rather than
trying to fix the problems that matter.

I will address this in the documentation (where it belongs). Trust me
in that you do not want such "normalization" as it hides mistakes in the
calling app (e.g. you shouldn't be trying to measure elements that have
no actual dimensions). ;)

JQuery is even more ludicrous in that it "normalizes" CSS height/width
to fit the one box model they've heard of. So there is really nothing
practical you can do with the measurement (e.g. adjust it). :)

Credit to MooTools for not going down this particular road to nowhere.
It's the one thing they did right. :)
 
D

David Mark

jdalton said:
Hi David,

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)

Not sure if you are aware of it, but you've got the wrong end of the
stick (at the moment) with the builder. Some of your carps are about
issues that have been fixed in the scripts on the Downloads page. Yes,
those are minified. Tough shit. If you really want to know, you can
get around that.

As mentioned several times in my forum, I haven't updated the builder's
source in a couple of weeks as there have been a lot of additions (as
well as a few bug fixes). It's been a hell of a first month for this
thing. The original code that has sat around for two years is
irrelevant now (except perhaps to those who are grasping for any excuse
to denigrate).

And good luck with the whole insanity thing. We're done here.
 
A

Andrew Dupont

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

This is the most hilarious thing you've ever said, David. There needs
to be a word for someone who behaves exactly like a troll, but is
completely sincere. I feel like I'm a shaman who just met my first
albino.

It's a miserable failure for jQuery to "punt" on quirks mode? Was it a
_different_ person named David Mark who said:
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.

And also:
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.


In other words, what you call a "design choice" when referring to your
library is a "punt" when referring to jQuery. I can see only one
surface difference: jQuery's punts are documented, whereas your design
choices are only publicized after a lengthy Usenet discussion.

No doubt you have some sort of rationalization for this. You'll likely
argue that jQuery is not "designed" but rather the weekend project of
some number of monkeys and typewriters.

When users run afoul of our frameworks' design choices, they can find
guidance on mailing lists and in IRC. Kind souls will explain the
reasoning behind the design choices and steer the questioner back onto
the beaten path.

When others point out failing or surprising results in _your_ code,
David, you snort and mumble something about design choices. No wonder
it's called "My Library" — it's clearly meant only for you. Nobody
else can read your mind. Nobody else understands why your design
choices are jQuery's punts.

This newsgroup is a comedic wonder. Don't ever change, guys.

Cheers,
Andrew
 
D

David Mark

Andrew said:
This is the most hilarious thing you've ever said, David.

Is it? Perhaps you've been asleep for the last few years (or working on
Prototype, which is roughly the same thing).
There needs
to be a word for someone who behaves exactly like a troll, but is
completely sincere. I feel like I'm a shaman who just met my first
albino.

You have an albino?
It's a miserable failure for jQuery to "punt" on quirks mode? Was it a
_different_ person named David Mark who said:


And also:



In other words, what you call a "design choice" when referring to your
library is a "punt" when referring to jQuery.

A design choice is a conscious decision (as in returning null to signify
a failure in the markup). jQuery claimed for years that it worked in
quirks mode. That was proved wrong (by my reviews), so they "announced"
in their forum that they were "punting". That's ridiculous for a script
that claims to "smooth over" browser differences. And IE quirks mode is
not the only way to get varying box models. See also: XML documents,
XHTML documents, etc., etc. They are constantly surprised (and
irritated) by revelations that should not be revelations to "pro
Javascript" developers. ;)

And do you really think I "punted" because I couldn't figure out how to
loop through all of the ID/name dupes and find the "right" one? You are
quite the comedian yourself.

I can see only one
surface difference: jQuery's punts are documented, whereas your design
choices are only publicized after a lengthy Usenet discussion.

No, see above. jQuery's documentation is pathetic (as is Prototype's).
I've never claimed mine was anywhere near comprehensive, but at least I
understand the code enough to write about it (and I've been writing more
of late). And we discussed the ID/name thing back in 2007 during the
CWR project. As far as I am concerned, returning null to signify an
underlying problem with the markup is far superior to superficially
glossing over it.
No doubt you have some sort of rationalization for this. You'll likely
argue that jQuery is not "designed" but rather the weekend project of
some number of monkeys and typewriters.

Clearly it is. Again, where have you been?
When users run afoul of our frameworks' design choices, they can find
guidance on mailing lists and in IRC.

Now that's the funniest thing I've heard all day. Guidance by the
blind? That's a good way to go off a cliff.
Kind souls will explain the
reasoning behind the design choices and steer the questioner back onto
the beaten path.

Not hardly (stifling uproarious laughter). Do some research. Their
forums are full of clueless meanderings, but largely bereft of informed
advice. Often the programmers are more confused than the users.
When others point out failing or surprising results in _your_ code,
David, you snort and mumble something about design choices.

Nonsense. Visit my forum and realize that the one guy who is finding
"surprising" results _here_ is hardly sincere (his latest folly was
comparing my DOM traversal to QSA).
No wonder
it's called "My Library" — it's clearly meant only for you.

Nope. It started out as an example. jQuery is the only one of the
"majors" that tried to imitate its techniques; but, of course, they
failed as they didn't understand what they were aping.
Nobody
else can read your mind. Nobody else understands why your design
choices are jQuery's punts.

You really like to generalize, don't you? Do you consider their
attr/removeAttr BS to be a "punt?" If so, go back about two years and
start reading.
This newsgroup is a comedic wonder. Don't ever change, guys.

And what does this newsgroup have to do with My Library?

And never mind "punts", how about forfeits:-

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/bf5fdb575cd7b354

Every one of those browser sniffs is an admission by the developer(s)
that they couldn't make their designs work, so opted instead to put up a
false front so that the users can delude themselves into thinking their
applications are cross-browser. And then the next versions of the three
or four "supported" browsers come out and it is back to the drawing
board (re-download the whole sorry mess again, re-test everything).
It's an endless cycle of futility. And none of this is news. Your
"rock solid" library is a pile of horse feathers.

Start here:-

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

....and maybe one day you will be competent to write cross-browser
scripts. Until then, please stop trying to save the world from the
"buggy" browsers with your non-solutions. Thanks!
 
J

jdalton

Hi David,
Interesting you went with an (almost) all-IE line-up this time. More
chicanery? And don't talk to me about IE compatibility view.
Glad the word-a-day calendar is working out for you. If I didn't
present IE tests you would probably still complain.
Looks pretty inconclusive (not to mention spotty) now. So much for your
"more accurate" tests. ;)
How so ?

The original code that has sat around for two years is
irrelevant now (except perhaps to those who are grasping for any excuse
to denigrate).
Whatever. Your lib from the builder or from the download page yields
the same results.

Visit my forum and realize that the one guy who is finding
"surprising" results _here_ is hardly sincere (his latest folly was
comparing my DOM traversal to QSA).
Your QSA-addon cannot be considered because it doesn't address any of
the bugs that QSA has. I have provided plenty of results that don't
use QSA and your lib is still one of the slowest.


On Jan 28, 1:18 pm
Each instance
of the latter is an admission by the author(s) that

On Feb 9, 7:18 pm
Every one of those browser sniffs is an admission by the developer(s)
that they couldn't make their designs work, so opted instead to put up a
Oh dear, he has started to repeat...


Updated tests with the mylib from
cinsoft.net/mylib-downloads.html

WinXP
-----

Opera 9.25
49 81 29 40* 151 90 42

Opera 9.50
159 146 57 112* 347 173 123

Opera 9.64
127 127 47 98* 316 143 108

Opera 10.10
201 352 62 109* 554 426 368

Chrome 1.0.154.36
252 407 139 279* 849 476 448

Chrome 2.0.172.28
267 615 144 335* 1499 830 716

Chrome 3.0.195.21
350 946 161 114* 2160 1333 970

IE6
29 47 18 35* 69 60 24

IE8 (Compatibility View)
61 97 38 81* 234 117 64

Firefox 3.6
244 305 188 99* 922 354 318


OSX 10.4
--------

Safari 2.0.0
1 0 9 1* 10 5 0

Safari 2.0.4
2 0 2 3* 15 0 2

Safari 3.04
17 20 13 15* 54 24 16

Safari 3.1
177 302 84 124* 562 387 362

Firefox 2.0
7 12 7 7* 28 14 7
 
D

David Mark

jdalton said:
Hi David,

Glad the word-a-day calendar is working out for you. If I didn't
present IE tests you would probably still complain.

You are still here?

How so what? And once again, you've snipped out a good part of what you
are asking me to reply to. Incorrigible.
Whatever. Your lib from the builder or from the download page yields
the same results.

The same results for what?
Your QSA-addon cannot be considered because it doesn't address any of
the bugs that QSA has. I have provided plenty of results that don't
use QSA and your lib is still one of the slowest.

You have provided no such results. The only results that (falsely)
showed mine as "one of the slowest" was exposed as rigged.
On Jan 28, 1:18 pm

On Feb 9, 7:18 pm
Oh dear, he has started to repeat...

It's when people say one thing one week and another the next that
there's a problem. I've been saying much the same thing about browser
sniffing since the early part of the century.
Updated tests with the mylib from
cinsoft.net/mylib-downloads.html

Oh here we go. I could have saved you some time as the differences in
the newer build won't affect these tests (at least not significantly).
I was referring to some of your other "bug reports" (a few of which were
valid, but already dealt with).
WinXP
-----

Opera 9.25
49 81 29 40* 151 90 42

Opera 9.50
159 146 57 112* 347 173 123

Opera 9.64
127 127 47 98* 316 143 108

Opera 10.10
201 352 62 109* 554 426 368

Chrome 1.0.154.36
252 407 139 279* 849 476 448

Chrome 2.0.172.28
267 615 144 335* 1499 830 716

Chrome 3.0.195.21
350 946 161 114* 2160 1333 970

IE6
29 47 18 35* 69 60 24

IE8 (Compatibility View)
61 97 38 81* 234 117 64

Firefox 3.6
244 305 188 99* 922 354 318

It's obviously the same QSA vs. non-QSA con. I've seen the handful of
workarounds in the other query engines for QSA quirks. The idea that
they are complete is ludicrous (as is the idea that you need QSA for
anything but dubious tests). And their "slow lanes" are fantasy code,
so you might as well disallow all of them as they have to fall back to
those in some cases (not to mention that most browsers in use today do
not have QSA at all).

Once I formalize _exactly_ which selectors I will support, I will make
sure that all of the layers (DOM traversal, XPath, QSA) match (and on
more than one random document). From the testing so far, there have
been no issues (not that that proves anything).

I don't even need to test the other libraries as their logic is so
obviously wrong (and deafeningly documented at this point). Basically,
XPath and QSA will be close, but the wheels fall off with DOM traversal
(which means the wheels fall off in IE). I've seen them fail on my
basic test document (most in older browsers, but not all). And (at the
moment), the tests do not do much with attribute-based queries. That's
one of the areas where the others break down. It only takes one
miscount (or exception) to disallow the results.

In the meantime, take my advice and forget about using CSS selector
queries (certainly if QSA is involved). They are obviously inherently
over-complicated error-prone, no matter whose library you use. For
every query-based solution, there are methods available to produce a
query-less solution. Make use of those instead. ;)

For information on which selectors I assert are stable in My Library
(with or without QSA), see the test page:-

http://www.cinsoft.net/slickspeed.html

I'll find out regardless, but anyone who can show that the selectors
tested on that page have problems with my QSA add-on is welcome to speak
up. Eh, except you. I don't care to waste time with loopy lunatics. :(
OSX 10.4
--------

Safari 2.0.0
1 0 9 1* 10 5 0

Safari 2.0.4
2 0 2 3* 15 0 2

Safari 3.04
17 20 13 15* 54 24 16

Safari 3.1
177 302 84 124* 562 387 362

Firefox 2.0
7 12 7 7* 28 14 7

You know, the further back in browser history I go, the more the others
fail to qualify (due to miscounting or exceptions). It seems highly
unlikely that every one of these things (other than mine) passed every
test. ISTM that several of the "major" frameworks fail my SlickSpeed
tests (which are basically the originals plus a few extra like
..class1.class2) in IE8 (in one mode or another).
 
J

jdalton

Hi David,
You are still here? Yep


How so what?  And once again, you've snipped out a good part of what you
are asking me to reply to.  Incorrigible.

I snipped nothing out. That was your reply to the Opera results. If it
was to IE8 compatibility mode then the same question applies. How are
my tests *not* "more accurate" as you seem to be suggesting.
The same results for what?

My previous Slickspeed results, follow along now Mark.

You have provided no such results.
Denial

The only results that (falsely)
showed mine as "one of the slowest" was exposed as rigged.

No rigging going on. You haven't exposed anything except your
ignorance.
I've been saying much the same thing about browser
sniffing since the early part of the century.

That horse has been beaten to a pulp.

Oh here we go.  I could have saved you some time as the differences in
the newer build won't affect these tests (at least not significantly).

It took seconds to copy the file over no time lost. Yes, as I stated
the results were the same.

It's obviously the same QSA vs. non-QSA con.  I've seen the handful of
workarounds in the other query engines for QSA quirks.  The idea that
they are complete is ludicrous

No one said any of them are complete, your QSA code *is* 100%
incomplete, at least the others put an effort into fixing the bugs.

In the meantime, take my advice and forget about using CSS selector
queries (certainly if QSA is involved).
Some talk from the guy using a cheap QSA hack in his slickspeed tests.
cinsoft.net/mylib-qsa-min.js
cinsoft.net/speedtest_mine.html
You know, the further back in browser history I go, the more the others
fail to qualify (due to miscounting or exceptions).  It seems highly
unlikely that every one of these things (other than mine) passed every
test.  ISTM that several of the "major" frameworks fail my SlickSpeed
tests (which are basically the originals plus a few extra like
.class1.class2) in IE8 (in one mode or another).

What's your point? If I expand the test to more complex selectors the
others will continue to pass while yours fails.
 
D

David Mark

jdalton said:
Hi David,


I snipped nothing out. That was your reply to the Opera results. If it
was to IE8 compatibility mode then the same question applies. How are
my tests *not* "more accurate" as you seem to be suggesting.

If you didn't botch the quote, it's a first. And thanks for narrowing
down what you meant by "how so". In a nutshell, you first tested my
QSA-less stock version against QSA, which was ridiculous. And you'd
have probably got away with it if it weren't for some meddling kids. :)

Then you concluded from those results, which were supposedly "more
accurate" (in some unspecified way) for ascertaining the library
performance, that mine was the "one of the slowest". Correct me if I am
wrong (it is getting late), but your second set of numbers didn't show
mine to be "one of the slowest" at all. So which version is accurate
and what exactly does it predict?
My previous Slickspeed results, follow along now Mark.

Did you read all the way through? You misunderstood what I said about
the difference between the current builder source and what is on the
downloads page. And who is Mark? Do you fancy yourself a drill sergeant?
Babbling.


No rigging going on. You haven't exposed anything except your
ignorance.

LOL. You have your own perspective, that's for sure.
That horse has been beaten to a pulp.

And yet most of the "major" libraries and frameworks are still using
such error-prone methods (almost to the exclusion of anything else).
The only one that even tried (in 2008!) to wean themselves from browser
sniffing was jQuery. Of course...
It took seconds to copy the file over no time lost. Yes, as I stated
the results were the same.

And as I stated, that's not surprising.
No one said any of them are complete, your QSA code *is* 100%
incomplete, at least the others put an effort into fixing the bugs.

That dog don't hunt:-

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/7ee2e996c3fe952b#
Some talk from the guy using a cheap QSA hack in his slickspeed tests.
cinsoft.net/mylib-qsa-min.js
cinsoft.net/speedtest_mine.html


What's your point? If I expand the test to more complex selectors the
others will continue to pass while yours fails.

Define "more complex" selectors? If they are not among those on my
SlickSpeed page (the ones I have asserted to support), then you are just
talking shit again. The point is that the others fail on those basic
tests on that one basic document (and not just in ancient browsers
either), yet seem oblivious to that fact, even after all of these years.
What do they think they are doing latching onto more problems with QSA?

Now, if I add a few rows using one of those simple selectors, which all
of the others assert to support as well, all hell will break loose (in
all but mine, of course). You do understand that, right? If not,
compare the attribute handling in theirs to:-

http://www.cinsoft.net/attributes.html

Should be a real eye opener (talk about incomplete!) ;)

And yes, I've transplanted almost every bit of that into My Library at
this point. You'll also notice that the newer one (from a few months
back) eschews the whole name/type node switcheroo. What does that tell
you? Or perhaps it already told you. ;)
 
J

jdalton

Hi David,
In a nutshell, you first tested my
QSA-less stock version against QSA, which was ridiculous.
It depends on the browser. In fact I first posted numbers that didn't
rely on QSA http://groups.google.com/group/comp.lang.javascript/msg/c62007cad51f2404
And you'd
have probably got away with it if it weren't for some meddling kids.  :)
Gotten away with what ? I never said the tests contain your QSA hack,
erm addon.
Then you concluded from those results, which were supposedly "more
accurate" (in some unspecified way) for ascertaining the library
performance, that mine was the "one of the slowest".
I explained it repeatedly, you must have tuned it out.
Correct me if I am
wrong (it is getting late), but your second set of numbers didn't show
mine to be "one of the slowest" at all.
You are wrong. The majority of my tests show your lib as one of the
slowest.
So which version is accurate
and what exactly does it predict?
Both. They aren't inconsistent. You know exactly what it predicts, I
can repeatedly, in multiple browsers, versions of browsers, without
QSA, show that your lib is one of the slowest.
And who is Mark?
Do you fancy yourself a drill sergeant?
Naw, it was a typo it is late :D
LOL.  You have your own perspective, that's for sure.
I guess you do too :D
Yes, talking to yourself again (that's not crazy). Your rant was less
a review and more about nitpicking unrelated things. Again, no one
said any of them are complete, but your QSA code *is* 100% incomplete.
Define "more complex" selectors?  If they are not among those on my
SlickSpeed page (the ones I have asserted to support), then you are just
talking shit again.
So when you support dead browsers outside the scope of other
frameworks it's OK to compare your lib to them in that context, but
when I compare valid selectors that others support and you lack
support for that is crossing the line ?

The point is that the others fail on those basic
tests on that one basic document (and not just in ancient browsers
either), yet seem oblivious to that fact, even after all of these years.
They may fail a few attribute selectors or use weak object inference
in places, but your's fails many unit tests as well and lacks robust
selector support. So I guess you're in the same boat. Enjoy the
company.

You do understand that, right?  If not,
compare the attribute handling in theirs to:-

http://www.cinsoft.net/attributes.html

Should be a real eye opener (talk about incomplete!)  ;)
I guess I could say the same about your selector support. Sure they
have bugs, oh well, yours is incomplete and buggy too.
What does that tell you?  Or perhaps it already told you.  ;)
It tells me your persistent winking creeps me out.
 
A

Andrea Giammarchi

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.

PureDOM is optimal and linear for what it does, perform tasks exactly
as they are described but I agree PureDOM should be better described
somewhere in TaskSpeed.

I will create a PureHack/PureCheat version so that games will be
basically over for whatever library and I wonder at that time who
would be interested in PureHack "chart column" anymore ... this is not
interesting to me, nobody needs to demonstrate a direct innerHTML is
faster than a function call with inside the same operation, we all
know this, and it's kinda obvious to me.

However, since devs expectation about PureDOM seems to be the fastest
hack ever, rather than a linear way to solve tasks as described, I
guess this column to compare should be there.

Regards
 
R

Richard Cornford

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

So nothing like being consistent?

But, assuming your tests make sense, ...
<snip>

A reasonable question, given how botched the 'pure DOM' part of
TaskSpeed turned out to be.

Looking at those test pages I observe that each HTML page that gets
queried makes lots of referees to:-

<URL: http://davidmissedthemark.com/slickspeed/system/blank.gif >

- which all get HTTP 404 responses (with quite a sizable (50Kb) 404
page body). It seems unlikely that failing to find the images would
have much, if any, impact on the results of these test, but it would
be nice to see test set-up functioning correctly before anyone started
using it.

Each of the test pages differ in the 'JS library' that they import and
a single line of code that calls the querying method from that
library, as you would expect. The following is the dojo example of the
actual test function from:-

<URL: http://davidmissedthemark.com/slickspeed/system/dojo.html >

| <script type="text/javascript">
| var context = document;
|
| function getLength(elements){
| return typeof elements.length == 'function'
| ? elements.length()
| : elements.length;
| }
|
| function test(selector){
| try {
| var data, elements, start, end,
| i = 0, comps = 0, distance = 0,

I don't see why these variable declarations are here inside the - try
- block instead of being at the beginning of the function body, but
their location will make no practical difference.

| times = [],
| start = +new Date();

The above is the recording of the start time for this test.

| function once() {
| return dojo.query(selector, context);

This is the line that calls the "library's" selector, and the only
point of difference inside the test function between the different
libraries.

| }

But what is this apparent function declaration doing here (in this
location) at all? ECMAScript syntax rules do not accommodate a
function declaration inside a block, and would not accept the above as
a function expression because then you would have an
ExpressionStatement that started with the - function - keyword, which
is forbidden.

So the only thing that is going to allow the above to be acceptable in
this location is going to be the language implementation supporting a
syntax extension. Most of them do, but there are two distinct styles
of syntax extension that accommodate apparent function declarations in
Statement contexts. The first is the IE style, where the apparent
declaration is seen as a function declaration despite its context and
'hoisted' to the being of the function body, evaluated during variable
instantiation, and so will have no impact here. The second, on the
other hand, is the style of syntax extension that introduces the
concept of a FunctionStatement, which gets evaluated at runtime just
like any other statement. The problem with that is that we have
already recoded the start time, and now we are going to be timing the
act of creating a function object as the result of a
FunctionStatement, but only in environments that provide that
particular syntax extension.

There really never was any need for the - once - function to be
declared inside a Block, and sticking with the vanilla ECMAScript
syntax would have avoided a variation in the test process across
platforms.


| (selector);

And what is this doing here? Either it is doing nothing at all (which
is what ECMA 262 says it should do), in which case why is it here at
all, or it is perhaps some attempt to call the preceding function (as
if it was a function expression, by some syntax extension where
ExpressionStatements are allowed to start with the function keyword).

This could do with being explained/justified.


| elements = once();
|
| do {
| comps++;
| once();
| } while ((distance = +new Date() - start) < 200);

This is the main timing loop. The - once - function gets called once
in order to set - elements -, - comps - is incremented and - once -
called again (meaning it has now been called twice since the start of
the timing), and then the - while - expression is evaluated. This
evaluation of the - while - expression involves the creation of a new
Date object, so the rate of creation of date objects is significant
for the test.

I wonder why the unary plus operator is applied to the Date object, as
the subsequent subtraction operation would force type-conversion of
its operands to numeric, but that is more a little odd than
significant.

The most important thing in this expression is the number 200 at the
end of the expression. It means that if the time reported by the new
Date object is more than 200 milliseconds after the date reported by
the original (start) date object then the - while - loop will be
stopped. That is, this test will terminate as soon after 200
milliseconds as the performance of the query method plus the rate of
Date object creation will allow.

As I have said before; I would not trust timing results that did not
differ from each other by less then 200 milliseconds. Dates in
browsers are just not that precise in the worst cases. Having the
whole test take little more than 200 milliseconds is quite likely to
see the influence of background tasks on the computer combined with
timing inaccuracies render the results meaningless.

Now, suppose that after the first pass through the - do - loop body
the 200 milliseconds has elapsed; the - once - function has been
executed twice, and - comps - has been incremented to the numeric
value of 1. This means that - comp , - as a measure of how many
operations have been performed within the timed period, is 50% off the
correct number. This error is reduced as the number of operations
performed increases, but it does mean the test is going to exaggerate
its built in bias against the worst performing 'library'.

I wonder what the point of assigning the millisecond duration to the -
distance - variable is. When the - do - loop ends this value will
(minus the inaccuracies of javascript Date objects) contain the amount
of time taken for the number of operations actually performed (plus
any function creating resulting form FunctionStatement syntax
extensions, and a certain amount of Date object creation, etc.). So
this value, combined with the - comp - value (if it wasn't up to 50%
inaccurate) should be able to provide the important 'operations pre
millisecond' result of this test. But strangely - distance - is never
referenced again, and so assigning it a value here is just another
operation being timed in the loop.

| return {
| 'time': 0,
| 'found': getLength(elements),
| 'ops': comps / 100

Here (assuming no exceptions have been thrown) the result is returned.
But what is going on here; - comps -, which not quite the number of
operations performed, is divided by a seemingly very arbitrary 100?
The loop is constrained by a 200 millisecond value. The test process
must come in at over 200 milliseconds; dividing by 200 would still not
be the right thing to do, but dividing by 100 seems distinctly odd.

The values reported by these test are certainly not operations per
millisecond, by any reasonable measure of what operations pre
millisecond could mean.

| };
| }
| catch(e){
| if (elements == null)
| elements = { 'length': -1 };
| return {
| 'ops': 0,
| 'time': ((+new Date() - start) / (i || 1)) || 0,
| 'found': getLength(elements),
| 'error': (e.fileName || '?.js')
| .replace(/^.*(\/[^\/]+)$/, '$1') +
| '#' + e.lineNumber + ': ' + e.message
| };
| }
| };
|
| test.name = "dojo1.4.js?1264409293";
|
| </script>

I am afraid that as it stands these tests are a mess, and I would not
attribute any meaning to their results.

Richard.
 
J

jdalton

Richard,

Thanks for the review. The tests were originally generated by PHP (I
am not the original author).
`(selector);` was part of that. If a custom method was defined it
would become `custom(selector)`.

I have made adjustments based on your review. The cost of `new Date`
is not really a concern because it is shared by all tests/libs.
The operations count for each is now higher, because more time is
allowed to pass, but the overall trend of MyLib being one of the
slowest (lowest number of executions per period of time) is unchanged.


IE8 (Compatibility Mode)
5,958 8,362 3,238 5,681* 17,768 8,630 3,499

Opera 9.25
7,675 13,137 4,688 6,599* 25,826 14,941 6,620

Opera 9.50
33,643 31,268 11,725 24,128* 71,395 36,086 27,150

Safari 3.0.4
2,715 2,561 2,333 2,325* 8,794 3,787 2,547
 
D

David Mark

Andrea said:
PureDOM is optimal and linear for what it does, perform tasks exactly
as they are described but I agree PureDOM should be better described
somewhere in TaskSpeed.

Well, that depends on your definition of "optimal".
I will create a PureHack/PureCheat version so that games will be
basically over for whatever library and I wonder at that time who
would be interested in PureHack "chart column" anymore ... this is not
interesting to me, nobody needs to demonstrate a direct innerHTML is
faster than a function call with inside the same operation, we all
know this, and it's kinda obvious to me.

You are really defensive. And what is it you plan to do that is "cheating?"
However, since devs expectation about PureDOM seems to be the fastest
hack ever, rather than a linear way to solve tasks as described, I
guess this column to compare should be there.

Whatever. Is this a contest?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top