[webkit-dev] setTimeout as browser speed throttle

[David Hyatt]

On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote:

>
> I can appreciate that you aren't interested in revisiting this  
> problem after having resolved it finally by adding the clamp.  I  
> believe you when you say you had compelling evidence too.
>

We are interested in revisiting the problem or we wouldn't be  
suggesting a new high resolution timer API.  We have actually  
revisited this problem fairly regularly.  First we put in the clamp,  
then I added the scale-up code for nesting so that one-shots get  
unclamped, and we have been revisiting our Windows timer  
implementation as well.  This is definitely an area that we are open  
to improving.  I myself advocated lowering the clamp back when we  
first put in the nesting code (but got talked out of it over fear of  
animation incompatibility rather than CPU hogging).

We have hard data that no clamp was bad, since we had problems with  
top Web sites.  We just want to make sure that this accumulated data  
factors into the decision of what to do.  I think people came in a  
little too strong defending the 1ms clamp, when we had pretty solid  
data on our side that 1ms would be a problem, and everything got  
heated from there.

It seems to me that the obvious solution is to shift the clamp  
accounting for computers (and our engine) being faster now.  I think  
we just need to settle on a lower clamp value and make the change.

> My point was just that we wanted to feel the pain ourselves before  
> going a similar route.  We have yet to feel the pain substantially,  
> and so it is interesting to keep going, gathering more data points.
>
> (Our architecture is designed to allow users to see that it is a  
> particular website that is "misbehaving" and so we have a lot of  
> opportunity I think to raise the visibility of things like this and  
> to at least gather more data.)
>

I don't know how clear I was in the previous email, but basically it  
can take a lot of time before you see problems.  What happens is a  
site makes a change, screws up and puts in an unintentional setTimeout  
loop, and then they pwn the CPU of a browser with no clamp.  They  
don't discover it because every browser has a pretty high clamp.  When  
we had these issues, they'd basically crop up one site at a time every  
so often.  The good news is that usually the sites would fix the  
problems, but the bad news is it could take a while, and angry users  
would be switching to Firefox.

dave
(hyatt at apple.com)