jQuery vs. My Library

[Scott Sauyet]

And you fell right on your face (again).  You only tested a fast machine
and you weren't testing the right thing at all.  The QSA branches will
always be about the same (and My Library's QSA-less implementation is
almost as fast as they are).  How do you like that?

You heard it here first, folks! The latest version of David Mark's My
Library runs faster on old machine running browsers nobody uses
against those selectors he deigns to support than do two year old
versions of the more widely-used libraries, at least when he tweaks
the test framework every most one else uses intact! And this is how
he proves that his library is better. I'm finding less and less of a
reason to even try My Library.

Try as hard as you might to deny this, that is what your posts are
claiming.

-- Scott

 

[Scott Sauyet]

I ran the tests on iPhone - they seem to work OK, but for some reason
the results are set a huge distance down the page so it takes several
minutes to scroll to them. Can you fix that please? The result tables
appear briefly just after the text, but then are shifted so it appears
to be something to do with the default CSS being altered by script.

This is not something I can comfortably fix. The slickspeed tests are
maintained by the MooTools team. The original test is here:

http://mootools.net/slickspeed/

And it has a Subversion repository here:

http://slickspeed.googlecode.com/svn/trunk/

This is easily posted on any PHP-enabled server. It offers a config
file to supply the libraries you want to compare and a text file to
hold your selectors. But if I try to alter even the output format, I
think people used to these slick-speed tests would start to doubt
them. Obviously if you want to do that yourself, it would not be hard
to do, but I'm not sure how others would take your tests.

-- Scott

 

[Scott Sauyet]

Obviously not.  But you might want to consider one the way you are going
here.    Did you hear nothing Richard told you about speed tests?

Yes, Richard is right that performance testing on the most powerful
machines is not the right way to do micro-benchmarking. But for
comparisons of libraries, the point is to test their relative speeds
in whatever environments you care about. Perhaps for you, testing
Firefox 1 on an eight-year old machine is relevant. I don't find it
so, myself.

-- Scott

 

[Scott Sauyet]

You heard it here first, folks!  The latest version of David Mark's My
Library runs faster on old machine running browsers nobody uses
against those selectors he deigns to support than do two year old
versions of the more widely-used libraries, at least when he tweaks
the test framework every most one else uses intact!  And this is how
he proves that his library is better.  I'm finding less and less of a
reason to even try My Library.

Try as hard as you might to deny this, that is what your posts are
claiming.

  -- Scott

err, "the test framework most everyone else uses intact."

-- Scott

 

[joedev]

Hi,
Thanks for having this discussion

Dave,
think you could implement the tests for taskspeed as well?
http://yuilibrary.com/~msweeney/yui-tests/taskspeed/#
could be a good starting point.

Thank,
Joe

 

[David Mark]

Hi,
Thanks for having this discussion

Dave,
think you could implement the tests for taskspeed as well?http://yuilibrary.com/~msweeney/yui-tests/taskspeed/#
could be a good starting point.

Already on that. Er, at least for something called TaskSpeed. I
thought it was Dojo's thing (Peter Higgins?) Whatever. It will be up
shortly. Results indicate that "pure DOM" is not much faster than My
Library (for reasons that should be obvious).

 

[David Mark]

You heard it here first, folks! The latest version of David Mark's My
Library runs faster on old machine running browsers nobody uses
against those selectors he deigns to support than do two year old
versions of the more widely-used libraries, at least when he tweaks
the test framework every most one else uses intact!

No. Get your facts straight. I tested _your_ page which uses the
_latest_ versions of the other libraries. And there's no tweaking.
Unsupported selectors were commented out. That's it. So what are you
saying? That the results on the one fast PC you tested (which were
all very close) trump the massive lead I have in the older PC's,
phones, lesser browsers without QSA, etc.? Which results are more
important to the end-users?

And this is how
he proves that his library is better.

Don't be an idiot. SlickSpeed (and the query module itself) is far
less important than compatibility and the speed of the rest of it.
I've never advocated using queries for anything and I still don't.
What does that tell you?

I'm finding less and less of a
reason to even try My Library.

You are simply a disingenuous dip-shit.

Try as hard as you might to deny this, that is what your posts are
claiming.

Nope. See above.

 

[David Mark]

This is not something I can comfortably fix. The slickspeed tests are
maintained by the MooTools team. The original test is here:

http://mootools.net/slickspeed/

So what? Fix the one you copied to your server.

 

[David Mark]

Yes, Richard is right that performance testing on the most powerful
machines is not the right way to do micro-benchmarking.

And isn't that exactly what you did? See the problem?

But for
comparisons of libraries, the point is to test their relative speeds
in whatever environments you care about.

Uh, no. Let me try to put this kindly. You are an idiot.

They are all about the same in the one fast PC you tested. That's
even with mine _not_ using QSA. So those results don't matter at all
as they won't affect the users.

On the slower PC's and in browsers without QSA, it wasn't even a horse
race. That predicts what mobile devices and other lesser
environements will do.

So it doesn't really matter what _you_ care about, does it? And if
you are so stupid as to think testing QSA wrappers means anything,
then I can't help you. Hint: they'll all be about the same, so the
results don't matter. You have to test what these same libraries will
do everywhere else (e.g. without QSA). That's where the issues
lie.

Perhaps for you, testing
Firefox 1 on an eight-year old machine is relevant.]

You still don't get it. I tested it in the latest Chrome on that same
machine (and in IE8 in both modes). I posted those results too, but
perhaps you are cherry-picking your arguments. Another person posted
a whole slew of tests on newer machines (and at least one phone). You
didn't find those results relevant either? You just want to cling to
the idea that in a newer machine with QSA, there is an imperceptible
advantage to the libraries that foolishly rushed to insert QSA. Do
you not understand why they rushed into something stupid for no
palpable benefit at all? Apparently not as that would undermine your
"argument" completely.

I don't find it
so, myself.

See above, genius.

 

[David Mark]

err, "the test framework most everyone else uses intact."

Don't bother proofing this drivel. I already sank all of your
battleships. Didn't take thirty seconds. Think before you post next
time.

 

[David Mark]

err, "the test framework most everyone else uses intact."

Oh, and I fixed those combinator issues last night. I uploaded a new
mylib-min.js just for you. Let me know if you have any more issues
with it.

 

[Scott Sauyet]

here are some more results.

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

As pointed out, these tests were against two-year old versions of the
other libraries.

-- Scott

 

[David Mark]

As pointed out, these tests were against two-year old versions of the
other libraries.

As pointed out, my results were against _your_ test page, which
included the "lastest and greatest" libraries, which basically added
QSA on top of their old bullshit (without much benefit at all).
Amazing that mine can be competitive (more than fast enough), even
without QSA. Seems like a good reason not to foul things up with QSA,
don't you think?

The above link is a better test as it lets you know differences where
they will matter (e.g. when the latest libraries "thunk" back to DOM
traversal in browsers without built-in queries). Get it?

And I'll add columns for the newer library versions when I get a
chance. We already know the results though. About the same where it
doesn't matter (fast PC's with QSA) and My Library by about a hundred
lengths in anything less than that (which will include phones and
other lesser agents), where it does matter. Now I know you get it, so
don't hold your breath waiting for any major revelations on the Speed
Test page.

 

[David Mark]

what does "BP" stand for?

Typo. NP.

 

[Scott Sauyet]

Scott Sauyet wrote:

Oh here we go with the time-wasting.  

Yes, I'm starting to agree that reading your twisting pseudo-logic is
a waste of time.

When I called your bluff, you tried to change the argument. Do you
really think many people care how your code runs on ancient browsers
in FF1? When's the last time you say that browser in your logs?

If you want to say that the difference in performance is mostly a non-
issue, I will certainly agree with you. But you are the one who made
a point of bragging about it, and then pointed your latest library
against much older versions of the competition.

I don't have very old machines laying around to test with. There are
four computers in my house; all are slower than the work machine I
tested with yesterday, but none are dog-slow; they are all between one
and five years old. I've tested three of them, with whatever browsers
I still had on them (the majors, all at recent releases on my machine,
FF, IE8, and OP on my kids's, FF & IE6 on my wife's.) Perhaps we
don't represent average users, but I cover ever browser that has
appeared in the logs of three sites I checked. Although the numbers
were in most cases higher than I posted earlier, the only changes in
relative speeds was that MooTools and Prototype swapped places on my
son's Vista machine in both Safari and FF.

Also, it makes no sense to compare QSA to DOM traversal.  Think.

I have been thinking. I wish you would join me in this endeavor.

You say it makes no sense to compare these. The only way I can make
sense of that is if you're saying that your techniques are so much
better than the previous techniques of the other libraries, and that
users should spend their time contemplating the beauty of your code
instead of using the best tool for the job. Is that what you mean?
If not, why does it not make sense to compare the libraries as they
are built? Instead, you seem to be saying, "Well, you haven't hobbled
yourself to come down to my level; that's obviously not fair!"

Mine is way the hell faster where it matters (and competitive enough
where it doesn't, even without QSA).  Your tests proved me 100% correct..

So your changing your initial argument from saying that yours is
faster, then? Not it's simply "way the hell faster where it
matters."? Which clearly does not include powerful machines with
recent browsers.

Obviously not.  But you might want to consider one the way you are going
here.

No, sorry, there's only room for one lobotomized participant per
discussion, and you've already filled that spot.

That one is irrelevant as it includes unsupported selectors.

So, you think your lack of support is a *good* thing?

Yeah, that's the one I used.  Were the results unclear?  Executive
summary: a massacre.  I even posted a link to this thread from my forum..
   You should stop making a fool of yourself.

Why, though, when you provide such a great role model for how to do
it?

Who's downplaying them?  I clearly won by a landslide.  Thanks so much!  

I think you really believe this. Pathetic!

-- Scott

 

[David Mark]

Yes, I'm starting to agree that reading your twisting pseudo-logic is
a waste of time.

No. You are the lone twisted voice of illogic here. What is it you
don't understand?

1. QSA === no benefit, several drawbacks
2. No QSA === good tests where it matters

That's it.

When I called your bluff, you tried to change the argument.

As we have been over (and over), you lost the farm on that bluff.

Do you
really think many people care how your code runs on ancient browsers
in FF1?

There you go again. I tested lots of modern browsers too. Did you
forget or are you just an incorrigible, confusing little sod?

When's the last time you say that browser in your logs?

You just don't get it at all, do you? That was one browser tested.
One. It thrashes them in FF1-3 and is more than competitive (fast
enough) in the QSA-enabled FF3.5. Then there's IE7, IE8, Chrome, etc.

If you want to say that the difference in performance is mostly a non-
issue, I will certainly agree with you.

It's a huge issue in older (or slower) environments.

But you are the one who made
a point of bragging about it, and then pointed your latest library
against much older versions of the competition.

No. That test page has been up there since the end of 2007. And,
as we've seen, it makes more sense to use that than testing QSA
wrappers (where the differences are insignificant).

I don't have very old machines laying around to test with.

Then run browsers that do _not_ have QSA. Then you can get some
significant results.

There are
four computers in my house; all are slower than the work machine I
tested with yesterday, but none are dog-slow; they are all between one
and five years old.
Great.

I've tested three of them, with whatever browsers
I still had on them (the majors, all at recent releases on my machine,
FF, IE8, and OP on my kids's, FF & IE6 on my wife's.)
And...?

Perhaps we
don't represent average users, but I cover ever browser that has
appeared in the logs of three sites I checked.

You are still thinking about this in simplistic terms. The point of
testing older browsers is to eliminate QSA from the equation. For
one, you can put IE8 in compatibility mode to accomplish this.

Although the numbers
were in most cases higher than I posted earlier, the only changes in
relative speeds was that MooTools and Prototype swapped places on my
son's Vista machine in both Safari and FF.

So what?

I have been thinking. I wish you would join me in this endeavor.

You are the one that is not making sense. AFAICT, I don't _need_ to
add QSA at all at this point. It's more than fast enough without it.

You say it makes no sense to compare these. The only way I can make
sense of that is if you're saying that your techniques are so much
better than the previous techniques of the other libraries, and that
users should spend their time contemplating the beauty of your code
instead of using the best tool for the job.

You missed by a mile. There's little difference in the fast PC/QSA
results, so they don't really matter. There's a _huge_ difference in
the non-QSA results, which will apply to older PC's with older
browsers, mobile devices, etc. This where speed matters. Now do you
get it?

Is that what you mean?

No, but it is clear that my slap-dash selector engine from two years
ago is far superior to the "slow lanes" featured in the various
"major" libraries. For those end-users stuck in the slow lane, that's
a positive boon.

If not, why does it not make sense to compare the libraries as they
are built?

We've been over this. We _are_ comparing them as they were built
(when testing the latest libraries). One set of results is
significant, one is not.

Instead, you seem to be saying, "Well, you haven't hobbled
yourself to come down to my level; that's obviously not fair!"

No, that's not what I'm saying at all. If I add a QSA wrapper on top
of what I have, the insignificant results will converge a bit more.
Who cares? Then there are the significant results, which will never
change.

So your changing your initial argument from saying that yours is
faster, then?

It is _much_ faster where it _matters_.

Not it's simply "way the hell faster where it
matters."? Which clearly does not include powerful machines with
recent browsers.

In those, they are all about the same as they are using the browser's
built-in queries. At that point, the results are insignificant
(though it is telling that mine is competitive at that level, even
without QSA).

No, sorry, there's only room for one lobotomized participant per
discussion, and you've already filled that spot.
Twit.



So, you think your lack of support is a *good* thing?



Why, though, when you provide such a great role model for how to do
it?
Again.



I think you really believe this. Pathetic!

Anyone here that doesn't believe it (other than this loser?)

 

[Esa]

That'll lead to some fun discussions Like calling your band "That
Band"

http://en.wikipedia.org/wiki/The_Band

 

[Thomas 'PointedEars' Lahn]

With so many globals, I would suggest giving them full names as well
as the single-letter identifiers. E===Element, etc

That would conflict with any code that uses:-

Element.prototype.myFunc = [...]

Yes. It will likely end up as MyElement, MyForm, MyImage, MyDocument,
etc.

var myEl = MyElement('#test');

Or better myLib.getElement(...), as (structurally) suggested before?


PointedEars

 

[joedev]

Matt Kruse wrote:
With so many globals, I would suggest giving them full names as well
as the single-letter identifiers. E===Element, etc
That would conflict with any code that uses:-
Element.prototype.myFunc = [...]

Yes.  It will likely end up as MyElement, MyForm, MyImage, MyDocument,
etc.

var myEl = MyElement('#test');

Or better myLib.getElement(...), as (structurally) suggested before?

+1 Please do use a namespace

--Support http://wikileaks.org/

 

[Scott Sauyet]

IE 6 is 10 years old and my corporate clients still use it, and won't
upgrade any time soon, so ancient browsers are important.

Oh yes, I always test with IE6. I did forget to post those results,
because I didn't have it on the machine I used yesterday.

934 1105 1771 3825 1113.

Obviously MooTools falls down a bit and Prototype even more. The rest
were comparable.

I have colleagues who work for large development houses that *do* use
the "common" js libraries on a day-to-day basis. I learnt very early on
to not ask how their latest js project was going because of the violent
denunciation of whatever bug they had just discovered and were trying to
workaround. (I've been too "afraid" to ask why they don't drop using a
library).

I think it's worth testing older libraries in various environments.
What I objected to is the self-aggrandizing manner in which David
Marks promoted the spped of his library, upgrading his library in the
tests to the latest version, but leaving the other libraries with two-
year old versions. You know he didn't expect anyone to notice.

When I post some results he responds by saying that I'm testing the
wrong thing. Either the browsers are too recent or the computer is
too fast. It's nonsense, of course.

-- Scott

-- Scott