[webkit-dev] setTimeout as browser speed throttle

[Darin Fisher]

On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
>
> On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
>>
>>  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.
>>>
>>
>> I guess I don't expect it to make a huge difference but if you would like
>> to test a value higher than 1ms but less than 10ms in live code I'd
>> certainly love to hear the results.
>>
>
> When we have that data, we'll share it.  I'm not sure when that will
> happen.
>
>
> Are you planning to test a specific alternate interval?
>


I don't know what Mike is planning to do exactly.



>
> 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'm not really talking about developer expectation here so much as the
>> possibility that, if indeed a lower clamp is a performance improvement for
>> real sites, then said sites would noticeably slow down the moment you
>> unplug. As a user I would find that surprising and weird.
>>
>
>
> My laptop slows down considerably when I unplug it because of power saving
> settings.  I don't find that too unusual.
>
>
> Mine doesn't. Instead it slews the CPU clockspeed based on workload and
> shuts down components (including the CPU) whenver possible. Get a Mac. :-)
> In all seriousness, I see your point for Windows machines. User expectations
> for the unplugged state may be lower.
>

Yeah, OK ;-)




>
>  (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.")
>>>
>>
>> My understanding is that timeBeinPeriod(1) is currently on all the time in
>> Chrome, even when no short-delay timers are currently pending, thus leading
>> to constant greater power consumption. But there is no need for it to be on
>> when there are not fast timers pending. See
>> WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically
>> better approach than switching based on power management state. Feedback
>> welcome, though, and perhaps you will still come to a different conclusion.
>
>
> I think that is a good idea too, but it doesn't help when a fast
> setInterval is active.
>
>
> That is true. With the webkit.org version of SharedTimerWin, though, you
> can at least close the problematic tab when you hear your fan spin up and
> stop suffering any power drain. It may be that running slower is a better
> option.
>


Yeah, that's the trade off.  Close the offending tab or let it run, but more
slowly.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/4c3e9b79/attachment-0001.html