Prev: slickspeed config and mylib
Next: Simplest and best column sorting in HTML table?
From: Andrew Poulos on 26 Jan 2010 15:03
Running the latest release of jquery against the latest full release of
mylib under Windows XP SP3 with all the selectors of slickspeed on.

With Internet Explorer 7 the final times were
jquery: 364ms
mylib : 214ms

With Firefox 3.6 the final times were
jquery: 30ms
mylib : 58ms

With Chrome 4 the final times were
jquery: 6ms
mylib : 44ms

On some selectors one was slower, on others the other was slower

On some selectors eg. div[class=example] jquery returned a result in 0ms.

With div[class$=mple] and div[class*=e] jquery found more than 40
matches whereas mylib found 0.

With FF and Chrome, mylib returned errors for 5 selectors.

Andrew Poulos
From: Scott Sauyet on 26 Jan 2010 15:57
On Jan 26, 3:03 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote:
> Running the latest release of jquery against the latest full release of
> mylib under Windows XP SP3 with all the selectors of slickspeed on.
> [ ... ]
> On some selectors one was slower, on others the other was slower

Not surprising. The only place that is very interesting is when the
speed differences are large.

> On some selectors eg. div[class=example] jquery returned a result in 0ms.

Unfortunately, a millisecond seems to be the smallest interval JS
reports. So I assume if it's under 0.5ms, or maybe even if it's under
1ms, it will be reported as 0.


> With div[class$=mple] and div[class*=e] jquery found more than 40
> matches whereas mylib found 0.

Are those the only ones that are different? I tested with five
libraries, and there were eleven tests in which some libraries
disagreed.

In these nine, My Library disagreed with all the other libraries,
which all agreed with one another: "div + p", "div ~ p", "h1
[id]:contains(Selectors)", "div:not(.example)", "p:nth-child(even)",
"p:nth-child(2n)", "p:nth-child(odd)", "p:nth-child(n)", and "p:only-
child". In these two (the latter only in FF), Dojo and Prototype had
results which disagreed with each other and with the other three,
which all agreed with each other: "p:contains(selectors)" and "div
[class!=made_up]". jQuery and MooTools always agreed with each other.

Did you have similar disagreements between the two libraries?

> With FF and Chrome, mylib returned errors for 5 selectors.

Probably it would be better to comment those out as they might affect
the speed test, but better still would be to have those ones fixed in
My Library if David would like to support them.

-- Scott
From: Richard Cornford on 26 Jan 2010 16:51
Scott Sauyet" wrote:
On Jan 26, 3:03 pm, Andrew Poulos wrote:
<snip>
>> On some selectors eg. div[class=example] jquery returned a
>> result in 0ms.
>
> Unfortunately, a millisecond seems to be the smallest interval
> JS reports. So I assume if it's under 0.5ms, or maybe even
> if it's under 1ms, it will be reported as 0.
<snip>

One millisecond may be the smallest time unit reported by javascript's
Date object, but there is an OS related factor in the rate at which the
clock ticks. Mac OSs have been reported as ticking the clock at 1
millisecond intervals (though I have never verified that for myself),
Windows XP ticks the clock at 10 millisecond intervals, whith Windows 98
and earlier (including MS DOS) ticking their clocks at ~56 millisecond
interval (or rather at a precise interval that is close to 56
milliseconds, but which I have never committed to memory). The result of
this that an activity taking 55 milliseconds may get reported as taking
zero time, while a 1 millisecond activity may be reported as taking ~56
milliseconds.

The 10 millisecond clock update rate of Windows XP is almost certainly
the most common, and my belief is that if an event to be timed is
reported as taking less than about 100 milliseconds (and preferably
nearer 200) then the result should be considered meaningless, as it
quite likely to be heavily influenced by the clock's update rate (in
addition to background activity and the OS task-swapping).

Richard.

From: toby.oconnell on 26 Jan 2010 18:33
On Jan 26, 12:03 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote:
> Running the latest release of jquery against the latest full release of
> mylib under Windows XP SP3 with all the selectors of slickspeed on.
>

I ran slickspeed with the Kindle DX, the slowest device I have access
to. This version of the Kindle DX was released January 19th, 2010 yet
*does not support QSA*. Because the device is so limited, I had to
make a custom test page at http://tobyoconnell.com/dx/2010-01-26/slickspeed/

My results with the Kindle are at http://tobyoconnell.com/dx/

In short:

jQuery 1.4.0: 3,742 ms.

jQuery fails a number of simple tests (likely in any browser not
supporting document.querySelectorAll). Note that this page does not
include the selectors for which My Library fails (Currently, My
Library does not support all selectors. To my knowledge, no
documentation exists which lists the supported selectors).

"My Library" 2010-01-26: 10,788 ms.

Ignoring jQuery's failing tests and two inefficient tests, My Library
performs about as quickly as jQuery 1.4.0. However, the poor
performance in handling selectors :nth-child(odd) and :nth-child(even)
becomes crippling on the slow Kindle DX browser. This can be witnessed
to a lesser degree in IE6. It appears that these two selectors hang
on a G1 phone.
From: S.T. on 26 Jan 2010 18:50
On 1/26/2010 3:33 PM, toby.oconnell(a)gmail.com wrote:
> In short:
>
> jQuery 1.4.0: 3,742 ms.
> ... To my knowledge, no
> documentation exists which lists the supported selectors).

http://docs.jquery.com/Browser_Compatibility
 |  Next  |  Last
Pages: 1 2 3
Prev: slickspeed config and mylib
Next: Simplest and best column sorting in HTML table?