[Webkit-unassigned] [Bug 26641] Safari consumes 100% CPU after leaving GMail open (gmail is installing a billion timers)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26641





--- Comment #11 from Dmitry Titov <dimich at chromium.org>  2011-06-24 10:45:24 PST ---
(In reply to comment #10)

> I'm seeing the same thing happening on techcrunch.com on low-end hardware. The site installs thousands of timers and sometimes the browser just can't keep up.

Isn't it the site issue?

> It looks like the minimum timer interval logic in DOMTimer.cpp doesn't have any effect, because it's only applied to individual timers. If a site makes 1000 separate setTimeout() calls, they will all try to run at once.

That logic is not intended to fix the 1000 timers issue. setTimout(foo, 0) is surprisingly popular pattern for doing work on the next JS invokation, 'yield' of sort. Sites often do it in a loop - do some work, schedule another portion etc, so without that logic many sites would go into 100% CPU even with a single timer. There were attempt to remove it and it broke a part of the Web :-)

> I think all JS timers for a given ScriptExecutionContext should be throttled together. If I call setTimeout() 1000 times, we should stagger their start times by minimumTimerInterval().

I don't see how it can fix the #1 from my list above. If each timer has at least minimumTimerInterval of work, they will still consume 100% cpu. If you meant to have a fixed interval between finishing of a timer callback  and any other timer starting the callback, this will unnecessary slow down pages that could otherwise benefit from better hardware. 

> We may also want to dynamically increase minimumTimerInterval() if timers are regularly missing their deadlines.

What exactly is that you are trying to find a solution for? Is it browser responsiveness to user input, so user still can close offending page? Fairness in CPU allocation between pages? Slowing effect of 'busy' page which is in a background tab on the page that is in the foreground tab? Effect all of this has on other applications in the system? Battery life being eaten w/o user realizing that?

The solution probably depends on the goal here. For example, "slow script" dialog is sometimes used in similar situations to let user close the resource-hogging page.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.