When I use setTimeouts, often the event has already occurred. So rather than
clamping, I'd suggest increasing the timeout up to 10ms rather than clamping it
at the start. Thus, if I specify 0, an immediate check would occur, then move
it up each time, maybe 1, 5, 10 would be optimum.
On Monday, September 29, 2008, at 10:58PM, David Hyatt [EMAIL PROTECTED]
wrote:
We encountered 100% CPU spins on amazon.com, orbitz.com, mapquest.com,
among others (looking through Radar histories). This was pre-clamp.
Web sites make this mistake because they don't know any better, and it
works fine in IE. It is a mistake these sites will continue to make,
and Chrome is the only browser that will be susceptible. Being
different from IE here is not a good thing. You will end up having to
evangelize sites over and over to fix 100% CPU spins that occur only
in your browser. Do you really want that kind of headache?
A new API will let Web apps get the performance they need while
avoiding compatibility problems.
dave
On Sep 29, 2008, at 10:06 PM, Maciej Stachowiak wrote:
On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote:
Hi,
One of the differences between Chrome and Safari is that Chrome
sets the setTimeout clamp to 1ms as opposed to 10ms. This means
that if the application writer requests a timer of less than 10ms,
Chrome will allow it, whereas Safari will clamp the minimum timeout
to 10ms. The reason we did this was to minimize browser delays
when running graphical javascript applications.
This has been a concern for some, so I wanted to bring it up here
and get an open discussion going. My hope is to lower or remove
the clamp over time.
To demonstrate the benefit, here is one test case which benefits
from removing the setTimeout clamp. Chrome gets about a ~4x
performance boost by reducing the setTimeout clamp. This
programming pattern in javascript is very common.
http://www.belshe.com/test/sort/sort.html
One counter argument brought up is a claim that all other browsers
use a 10ms clamp, and this might cause incompatibilities. However,
it turns out that browsers already use widely varying values.
I believe all major browsers (besides Chrome) have a minimum of
either 10ms or 15.6ms. I don't think this is widely varying.
We also really haven't seen any incompatibilities due to this
change. It is true that having a lower clamp can provide an easy
way for web developers to accidentally spin the CPU, and we have
seen one high-profile instance of this. But of course spinning the
CPU can be done in javascript all by itself :-)
The kinds of problems we are concerned about are of three forms:
1) Animations that run faster than intended by the author (it's true
that 10ms vs 16ms floors will give slight differences in speed, but
not nearly as much so as 10ms vs no delay).
2) Burning CPU and battery on pages where the author did not expect
this to happen, and had not seen it on the browsers he or she has
tested with.
3) Possibly slowing things dow if a page is using a 0-delay timer to
poll for completion of network activity. The popular JavaScript
library jQuery does this to detect when all stylesheets have loaded.
Lack of clamping could actually slow down the loading it is intended
to wait for.
4) Future content that is authored in one of Safari or Chrome that
depends on timing of 0-delay timers will have different behavior in
the other. Thus, we get less compatibility benefit for WebKit-based
browsers through cross-testing.
The fact that you say you have seen one high-profile instance
doesn't sound to me like there are no incompatibilities. It sounds
like there are some, and you have encountered at least one of them.
Points 1 and 2 are what made us add the timer minimum in the first
place, as documented in WebKit's SVN history and ChangeLogs. We
originally did not have one, and added it for compatibility with
other browsers.
Currently Chrome gets an advantage on some benchmarks by accepting
this compatibility risk. This leads to misleading performance
comparisons, in much the same way as firing the load event before
images are loaded would.
Here is a summary of the minimum timeout for existing browsers (you
can test your browser with this page:
http://www.belshe.com/test/timers.html
)
Safari for the mac: 10ms
Safari for windows:15.6ms
Firefox: 10ms or 15.6ms, depending on whether or
not Flash is running on the system
IE : 15.6ms
Chrome: 1ms (future - remove the clamp?)
So here are a couple of options:
1) Remove or lower the clamp so that javascript apps can run
substantially faster.
2) Keep the clamp and let them run slowly :-)
Thoughts? It would be great to see Safari and Chrome use the same
clamping values.
Or there is option 3:
3) Restore the
