[webkit-dev] setTimeout as browser speed throttle

[Maciej Stachowiak]

On Sep 30, 2008, at 10:42 AM, 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.

That seems like incorrect reasoning to me. unclamped setTimeout(0)  
does not break processing of user events in a single-process browser  
(I tested). But it will equally drain your laptop battery and produce  
a great deal of heat and noise with single-process and multiprocess  
architectures.

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

At the extreme, performance issues can be 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.

I think if we agree that there should be some lower bound on the  
normal timer API, to protect against sites only tested in normal  
browsers, then we would want to also introduce a high resolution timer  
API with no limit for aware apps to use. In which case it seems  
prudent not to change the timeout from the range of what other  
browsers do. That way there is no risk to legacy content, but new  
content can get the full benefit (rather than being throttled to 3ms  
or 1ms).

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/798b0bd7/attachment.html