[webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

Hi Peter,

On Sep 30, 2008, at 8:42 PM, Peter Kasting wrote:

> 2008/9/30 Mike Belshe <mike at belshe.com>
> As for keeping the fan off - if we could keep the CPU idle a 3ms  
> minimum timeout loop does that resolve your concern?
>
> Followup to my earlier post, based on this.
>
> I realize that one reason why we (Chromium folks) have not been as  
> concerned about CPU usage is that in a multi-process world,  
> excessive CPU is an annoyance, but doesn't completely break the  
> app.  This wouldn't necessarily be the case in a single-process  
> consumer of WebKit, e.g. Safari, where a page in a tight JS loop  
> could make the whole browser less responsive.  This seems like a  
> legitimate reason to be concerned about excessive CPU usage.  Mike's  
> suggestion that we can find a minimum timeout value (e.g. 3 ms)  
> where the CPU doesn't get pegged seems reasonable if this is the  
> main issue.
>
> And a few more thoughts on app compat.  Using more CPU is not an app  
> compat concern.  The CG GIF decoder that Safari uses burns 10x the  
> CPU that Gecko's does, such that on various animated GIFs I can hit  
> 60% of one of my (very fast!) cores just animating a single image in  
> Safari.  But no one has ever presented this as a "web app compat"  
> issue, even though tons of web pages use animated GIFs; it's just a  
> bug/optimization opportunity.  Chromium uses extra CPU due to having  
> plugins out of process.  Gecko uses more CPU to relayout than  
> WebKit.  None of these are compatibility issues.  The comments on  
> bug 6998 imply to me that the 10ms cap was put in because Safari was  
> eating more CPU than other browsers, not because there were  
> animations running at the wrong speed or stylesheet loads not being  
> sensed soon enough.
>
> I think if we can agree that not pegging the CPU, rather than  
> precisely matching other browsers (which is impossible due to their  
> 60% variance from each other), is the chief objection to uncapped  
> timers, it will be easier to move forward.

The problem is not only confined to single processor systems. As  
others have mentioned the bigger problem is the waste of resources.  
The length of the timeout is not the full piece of the puzzle. There's  
also problems with what the application does at the end of each  
timeout. This often needless processor use ends up draining batteries,  
increasing heat and wasting energy (even with a multiprocessor system).

> 2008/9/30 Alexey Proskuryakov <ap at webkit.org>
> Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а):
> > As for keeping the fan off - if we could keep the CPU idle a 3ms
> > minimum timeout loop does that resolve your concern?
>
> Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur
> non-trivial processor usage.
>
> Your comment in that bug was that it was 3.7% of CPU on your  
> machine.  3.7% for "as fast as possible" doesn't seem like a huge  
> burden.  That suggests authors could write tight loops at 3ms delays  
> and still only burn 10% of the CPU.  I think that's a reasonable  
> proposal.

Again, the length of the timeout is not the only thing determining CPU  
usage. The response to the timeout also influences CPU usage. If the  
timeout is clamped at 3ms instead of 12ms, then it is using the  
processor 4X as much (assuming that it doesn't also introduce  
synchronization problems the author didn't anticipate). That is quite  
significant. Given the growing importance in mobile processing it  
seems rather irresponsible to promote this waste of processor resources.

Take care,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/a2f0aedb/attachment.html