From: David Mark on 10 Feb 2010 14:10
> 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.
As noted in the recent review of QSA tack-ons, your test is rigged
(compares QSA to a script). Thanks for trying though.
[snip bogus results[
From: jdalton on 10 Feb 2010 14:39
I don't think prending your argument is valid is getting you anywhere
(honestly it's pathetic). Everyone can see that the overwhelming
majority of browsers I have been reporting don't use QSA. Nothing is
rigged, you simply can't accept that you have *failed* to produce a
faster/more complete alternative.
From: jdalton on 10 Feb 2010 14:52
On Feb 10, 1:39 pm, jdalton <john.david.dal...(a)gmail.com> wrote:
> I don't think prending your argument is valid is getting you anywhere
I don't think pretending...
From: jdalton on 10 Feb 2010 16:12
> Your excuse was that QSA is "buggy in all browsers" (or something like that)
> and the valiant "majors" have been feverishly working to combat these
I didn't say "feverishly working to combat", but they do put forth an
> issues, but my add-on is oversimplified because it doesn't include the
> slew of workarounds present in theirs.
Yes it is overly simplified. You are completely ignorant to the issues
because you have failed to research them.
> All I've seen is that your tests are full of holes. And there's not a
> single shred of evidence that the non-QSA browsers show mine as "one of
> the slowest".
Denial. I am curious how do you rationalize using a benchmarking tools
created by MooTools/Dojo devs when you bash them and their
> Quite the contrary, I run (relevant) tests on non-QSA
> browsers all the time and mine is always one of the fastest (usually the
> fastest by a large, even exponential margin),
Delusional. You aren't running my tests or tests that accurately show
> I consider your "results" to be nothing more than random numbers. And
> given your track record of one half-truth (or outright lie) after
There is no half truths. I have been consistent.
> another, they could very well be made up.
> point (and hard to imagine anyone else does either, excluding your
> various alter ego sock puppets).
Check the IP addresses from the other posters non map to me.
> And the others are all ill-equipped to handle non-QSA browsers as they
> can't even read attributes straight, even with browser sniffing in
> place. It's spelled f-o-l-l-y. Get it?
You are hung up on the few attribute bugs they have. You don't get it.
> > Nothing is
> > rigged, you simply can't accept that you have *failed* to produce a
> > faster/more complete alternative.
> Not hardly. You simply can't admit that you don't know what you are
> And you need to stop focusing on queries anyway.
> How many times do I have to tell you that they
> are the least important issue at hand.
Then why do you promote your false performance ?
> Trying for weeks to come up with a query-based test that proves my
> library is "one of the slowest" just makes you look like a jackass.
Weeks ? I just posted the Slickspeed tests yesterday.
> And "more complete?" Are you kidding? Mine works on virtually
> anything, past, present and (very likely) future.
> Theirs are software
> of the month clubs trying (and failing) to keep with just the latest
> versions of three or four browsers (in their default configurations).
> One is almost zero cost of ownership, the others are bottomless money
> pits. Get that? ;)
Mindless ranting. Ahh that creepy wink again.
From: David Mark on 10 Feb 2010 16:10
So what do you have here anyway? Looks like the typical hand-picked
result set. Why not stay consistent from one post to the next? And why
all QSA-less browsers this time around? Why do we need your hacked
version of SlickSpeed for that? Wasn't the whole point to show more
detail than the 0ms QSA results?
Assuming these are less like random numbers than the previous batches
(and aren't made up).
> IE8 (Compatibility Mode)
> 5,958 8,362 3,238 5,681* 17,768 8,630 3,499
As mentioned, all of the others are disallowed in compatibility mode
(for reasons that should be obvious to anyone who actually reads this
group). Hint: they can't deal with buggy MSHTML attribute methods.
They don't "punt", they throw a Hail Mary into the stands.
So you threw out your previous attempt at "more accurate" tests and came
up with a new batch. And these incomplete results hardly indicate mine
is "one of the slowest". It's unclear if they indicate anything more
than delusion on the part of "jdalton" and a couple of sock puppets. ;)
> 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
Odd choices. Do you throw darts at a list of browsers? Or perhaps you
cherry-pick the results that appear to support your ridiculous claims?
Opinion appears divided on the validity of your tests (and the relevance
of the results). Richard says they are meaningless, you say they mean
everything. Who are we to believe? :)
I say none of these rapid-fire query tests has much in the way of
practical value. The TaskSpeed tests are clearly a better approximation
of a Web application. But at least the other SlickSpeed variations (all
but yours) have some modicum of acceptance in the industry.
Every other test out there shows mine as fast (or much faster). Your
pet test, which doesn't seem to have any practical merits at all, shows
it as middle of the pack at worst. So your ravings about "one of the
slowest" would seem to indicate you are a crackpot.