[webkit-dev] setTimeout as browser speed throttle

[Dave Cronk]

 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
>
>