[webkit-dev] setTimeout as browser speed throttle

[Maciej Stachowiak]

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

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

Cheers,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/02a9e882/attachment.html