[webkit-dev] setTimeout as browser speed throttle

[Darin Fisher]

On Wed, Oct 1, 2008 at 5:26 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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 am indeed interested in passive feedback from users and web developers.
 But I'm also interested in the anonymous, opt-in aggregate data collection
that we can perform ourselves (as Linus mentioned).  The challenge is to
find a way to be confident in selecting a clamp value.  Feedback from users
seems like an important metric but it is not the only metric.



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

I think that users often only notice high CPU usage after it has been
occurring for a while.  At that point it is frequently not well correlated
to recent browsing activity.  You might have already opened other tabs.
 Maybe it was even a background tab that started acting up.  In a single
process browser, a user just sees the browser process consuming CPU.  In
Chrome, they see a particular tab (or maybe a set of tabs) consuming CPU.
 So they can diagnose the problem and point fingers more easily.

In short, our architecture makes me more willing to take risks with
setTimeout clamping than I would be otherwise.  This is a good thing I think
because we have the opportunity to test this out and get more data without
risking as much.




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

Yeah, I realize that this is a Windows only API.  I think we just disagree
here.  In my opinion since setTimeout clamping is so varied across browsers
and even varies in Firefox depending on whether or not a flash animation is
going, the expectation of consistent clamping has to be low.  Or at least it
has to be the case that it doesn't matter much if different browsers have
different clamping values in practice.  So I think there is room to do
interesting things related to different power management states.  Anyways,
I'm just telling you what we are considering doing.

(I don't understand your comment about not having to have it on all the
time.  Surely if a page is asking for a fast setTimeout repeatedly, it would
be on "all the time.")

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/b41040ee/attachment.html