[webkit-dev] setTimeout as browser speed throttle
mjs at apple.com
Mon Sep 29 20:06:36 PDT 2008
On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote:
> 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
> 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
> 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
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
3) Possibly slowing things dow if a page is using a 0-delay timer to
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:
> 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 clamp for setTimeout and setInterval to 10ms for
compatibility, and add a new setHighResTimer API that does not have
any lower bound.
This would let aware Web applications get the same benefit, but
without any of the compatibility risk to legacy Web content. The main
argument against doing things this way is that it would add API
surface area. But that seems like a small price to pay for removing
the compatibility risk, and turning the change into something other
browsers would be willing to adopt.
I would like to propose an API along these lines for HTML5 but I would
prefer if we can achieve consensus in the WebKit community first.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev