[webkit-dev] setTimeout as browser speed throttle

[Maciej Stachowiak]

On Oct 1, 2008, at 5:03 PM, Darin Fisher wrote:

>
>
> On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> On Oct 1, 2008, at 1:24 AM, David Hyatt wrote:
>
>> 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.
>
> I'm with Hyatt. The reason we are having this thread is precisely to  
> revisit the problem.
>
>
> Good to hear.  From what you wrote, I thought you were disinterested  
> in considering lower clamp values for setTimeout, and that is what I  
> was referring to.  (I knew you supported a high-res timer API.)   
> From what you say below, however, I see that you are interested in  
> lowering the clamp value.  Sorry for misunderstanding.

I'm interested in finding out whether there is a value lower than 10ms  
but higher than 1ms that is (a) safe and (b) beneficial for  
performance on real sites. It seems clear to me that 1ms is not safe.

My impression from your remarks was that you thought 1ms is working  
fine, and that passively waiting to get more feedback from Chrome  
users was an ok way to confirm that it is fine. If that's not what you  
meant, then my apologies for misinterpreting. If it is what you meant,  
then I continue to respectfully disagree on both fronts.

>
>> 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.
>
> That is what I was alluding to when I said it took us 3.5 years to  
> first realize we had to add the clamp. The problems come and go, but  
> they are consistently a problem, and it can take a while to realize  
> it.
>
> Yup, I can totally see that happening.  This is why I highlighted  
> our architecture, which helps more squarely place blame on  
> misbehaving sites.  That should help developers and users more  
> easily see who to blame, which should help these issues get more  
> visibility and be resolved more quickly.  I may be wrong, but I'm  
> curious to find out.

This seems implausible to me. When a site misrenders, it is obvious  
which site is misbehaving, but users still usually blame the browser,  
not the site.

> Laptops on battery power are not an issue since we wouldn't want to  
> enable high-res timers on those systems.  timeBeginPeriod(1) being  
> too costly there.

There's no such thing as timeBeginPeriod on Mac or Linux. And I  
believe the timeBeginPeriod problem is solvable on Windows (there is  
no need to have it on all the time). Overall I think it would be poor  
form if site behavior changed depending on whether I was plugged into  
a power cable.

Regards,
Maciej

>
> -Darin
>
>
>
> However, the bug Mike cited seems to mention problems with the 1ms  
> limit on some real sites: <http://code.google.com/p/chromium/issues/detail?id=792 
> >. At least 5 sites are mentioned, including nytimes.
>
> I think we are converging on some good solutions (somewhat lower  
> basic clamp, new highres API) and I regret if this thread has felt  
> hostile to anyone.
>
> Regards,
> Maciej
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081001/534adb90/attachment.html