[webkit-dev] setTimeout as browser speed throttle

[David Hyatt]

We do this now.  We detect repeated setTimeouts and ratchet up to 10ms  
only after a repeated firing situation has been detected.

On Sep 30, 2008, at 9:48 AM, Dave Cronk wrote:

> 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" <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
>>>>
>>>> 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 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
>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev