[webkit-dev] setTimeout as browser speed throttle

[Mike Belshe]

Thanks for the concrete examples, Dave!  I tested all 3 of these, and
haven't yet found any problems.  But I don't have specific URLs.  I also
looked through the webkit bugs database as much as I could, and could not
locate them.
BTW - if the primary concern is not spinning the CPU, we could just drop the
throttle down to 2 or 3ms, and the CPU will be largely idle on most
machines.  In a few years, with faster processors, we'll be able to drop to
1ms and still have largely idle CPU.

Would 3ms be viable in your eyes?

Mike


On Mon, Sep 29, 2008 at 8:58 PM, David Hyatt <hyatt at apple.com> 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<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 )<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 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.
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/733a8442/attachment.html