Prev: slickspeed config and mylib
Next: Simplest and best column sorting in HTML table?
From: S.T. on 26 Jan 2010 18:51
On 1/26/2010 3:50 PM, S.T. wrote:
> 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

Nevermind, I read 'supported selectors' as 'supported browsers'
From: toby.oconnell on 26 Jan 2010 19:10
On Jan 26, 3:51 pm, "S.T." <a...(a)anon.com> wrote:
> On 1/26/2010 3:50 PM, S.T. wrote:
>
> > On 1/26/2010 3:33 PM, toby.oconn...(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
>
> Nevermind, I read 'supported selectors' as 'supported browsers'

Regarding the selector documentation, I was referring to "My
Library." It looks like the jQuery selectors are listed at
http://api.jquery.com/category/selectors/
From: RobG on 26 Jan 2010 20:26
On Jan 27, 7:51 am, "Richard Cornford" <Rich...(a)litotes.demon.co.uk>
wrote:
> 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.
>
> 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.

Test suites seem to rely on the browser's date object, which may be
based on an OS supplied clock or the browser's own. Firefox on XP
seems to have a 1ms tick, while IE 6's tick is around 15~16ms[1].

If the purpose of a test suite is to evaluate library speed, the a
very early step should be to evaluate the ability of different
browsers to resolve time to a sufficient accuracy or precision for the
results to be meaningful. Two results might be different by 100% (say
1ms and 2ms) yet fall within the precision of the timers used, and so
therefore are effectively equivalent.


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

Indeed. There are 40 selectors in the SlickSpeed tests, using 5
libraries and about 200ms for each test comes to 40 seconds for the
actual tests. Running the suite at <URL: http://mootools.net/slickspeed/
> takes about 55 seconds on my ordinary Windows XP box with Firefox.
The total time for the actual tests is less than 1 second.

So it should not be too hard to run a small set of initial tests to
determine the platform speed, then increase the size of the test
document to ensure most tests take around 200ms. Adding the overhead
of running the tests, results should be available in about 100
seconds. Pretty reasonable. It would not bother me if the tests took
15 minutes if the results were meaningful.

The tests should also use a custom document designed specifically to
test selectors in a variety of scenarios, not the random document
currently being used.

1. Code use to determine tick interval:

var t0 = new Date(),
t1 = new Date();

while ( !(t1 - t0)) {
t1= new Date();
}
alert('Tick interval: ' + (t1 - t0) + ' ms');


--
Rob
From: David Mark on 27 Jan 2010 12:16
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.
>
> With Internet Explorer 7 the final times were
> jquery: 364ms
> mylib : 214ms

Good.

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

Not good. Were you running with or without the QSA add-on? There is
a minified version with the add-on tacked on at:-

http://www.cinsoft.net/mylib-qsa-min.js

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

That definitely sounds like the QSA-less version. Not sure what
version of Chrome I've been testing, but My Library never loses (and
it isn't even close, except with the latest jQuery).

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

Those two are not supported and that tells me you are not using the
test page at:-

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

....where those two selectors are commented.

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

Those are unsupported. As I've mentioned a few times over the years,
if it isn't on the test page (link above), it isn't supported. ;)

From: David Mark on 27 Jan 2010 12:18
On Jan 26, 3:57 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> 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".

You need to get the lastest version. See previous post. By request,
I recently added the nth-child psuedo selectors. I'll add the
remaining three or four when I have a chance.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: slickspeed config and mylib
Next: Simplest and best column sorting in HTML table?