[webkit-dev] setTimeout as browser speed throttle

[Maciej Stachowiak]

On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:

>
> 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 think testing on already the known problem sites with different  
clamp values, and hunting for more problem sites in some active way,  
are probably the most valuable additional data gathering that we can do.

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

Our experience is that users often do notice what site is  
inadvertantly causing high CPU, because they file bug reports  
mentioning the URL, and pointing out that it doesn't cause the same  
problem in Firefox. Now, it might be that there are even more problems  
where the user does not identify the problem site and does not file a  
bug; I have no way to rule out that possibility.

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

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

The reason that I mention this is that on Mac and Linux systems,  
there's no special power-wasting system call to "enable high-res  
timers".

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

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

Regards,
Maciej