On 8/11/10 9:17 PM, Garrett Smith wrote:
On 8/11/10, Boris Zbarsky<[email protected]> wrote:
On 8/11/10 11:48 AM, Boris Zbarsky wrote:
javascript:var start = new Date(); function f(n) { for (var k =
n.firstChild; k; k = n.nextSibling) f(k); } f(document); alert(new
Date() - start)
Er, that had a typo. The correct script is:
javascript:var start = new Date(); function f(n) { for (var k =
n.firstChild; k; k = k.nextSibling) f(k); } f(document); alert(new
Date() - start);
My result is 1012
In what browser? Firefox 3.6? (And presumably on reasonably slow
hardware, if so.)
If so, really do try 4.0 beta. It's a good bit faster.
It's also highly contrived example. When you start doing any DOM
manipluation, particularly appending or removing nodes, you're going
to notice a lot larger times.
Well, sure, but you also won't be walking the entire DOM in JS like
this. The HTML5 spec scripts sure don't, last I checked.
Now the numbers are slightly larger; on the order of 230ms to 350ms.
Barely above human lag-perception. This is on a several-years-old
laptop as hardware.
How do figure that's barely above human lag perception?
The commonly accepted figure for when things start to feel laggy in UI
terms is 200ms. If someone clicks and nothing happens for more than
200ms then they perceive the response as slow. Otherwise they generally
perceive it as "pretty much instant".
-Boris
