[webkit-dev] setTimeout as browser speed throttle
hyatt at apple.com
Wed Oct 1 01:24:51 PDT 2008
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.
(hyatt at apple.com)
More information about the webkit-dev