532904 - Consider increasing the timeout/interval lower bound in hidden windows

Status: RESOLVED DUPLICATE of bug 633421

(Core :: DOM: Core & HTML, defect)

Description

[Boris Zbarsky [:bzbarsky]]

We clamp timeouts to 10ms.  In background tabs, minimized windows, windows not on the current desktop, can we get away with clamping them to, say 1000ms?  Might help with the cpu suck that is your typical google app....  On the other hand will break the (admittedly rare) case of some computation that's being done that you actually want the results of, and that is using timers to not freeze the UI.

Comment 1

[Marc Horowitz]

You could make the non-visible timeout clamp an about:config option.  Default it to 1000ms, and those rare people who need to do timer-driven non-ui-blocking background javascript computatation can set it lower.

Comment 2

[John J. Barton]

Are you proposing to cause 
  var timeoutID = window.setTimeout(code, delay);
to act as if |delay| has a lower limit of |1000|?

Firebug uses setTimeout with zero delay extensively as a simple version of 'yield'. I believe this is common among JS developers.  

If app developers want a 1000ms delay, they can specify it. If we think more devs should be using 1000ms delays we can try to reach out to them. 

I don't understand how this change makes anything better.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Are you proposing to cause 
>  var timeoutID = window.setTimeout(code, delay);
> to act as if |delay| has a lower limit of |1000|?

Yes, if |window| is not what the user is currently looking at.

> Firebug uses setTimeout with zero delay extensively as a simple version of
> 'yield'. I believe this is common among JS developers.  

Yes, that's precisely the problem.

Firebug would obviously be unaffected, since it's presumably running in the window the user is looking at, yes?

> I don't understand how this change makes anything better.

Right this second, I have about 40 tabs open.  These tabs, between them, have about 200 timers in flight at any given time, on timeouts ranging from 10ms (our lower bound; they page almost certainly tried for lower) to 500ms.  Most of these are doing absolutely nothing I care about other than wasting about 30% of the cycles on one of my CPU cores and draining my laptop battery.  For example, if I'm not looking at my google reader page I do not in fact want it checking for updates every 500ms.  Similar for gmail, etc.

Comment 4

[John J. Barton]

I agree 100% about the problem you are pointing to. I just don't think this is the right way to solve it.

Rather than changing the meaning of setTimeout(), I think a better solution is  simply suspending JS all non-visible windows, and introducing a new API for true background work. This would dramatically improve Firefox's apparent performance and its good for the planet too ;-).   Apps that really need to run hidden would adopt the new API.

As migration path, we can allow users to opt out of the suspension for particular pages say.

Comment 5

[Benjamin Smedberg]

Is that what users expect? I expect gmail to continue running, even when I switch away from it.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I think a better solution is simply suspending JS all non-visible windows

This would break existing music player apps, as well as breaking gmail, etc.  We're planning to introduce better APIs too, but I'm under no illusions about your typical web page using them, esp. if we're the only ones who have them.

Benjamin, were you replying to comment 4 or my comments?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Increasing the minimum timeout from 10ms to 1000ms is a 100X slowdown for JS that uses setTimeout(0) as a yield. That's pretty bad if you're hoping for that JS to eventually produce a result.

Maybe increase the minimum to 50ms and see how that goes? Still a significant saving, but audio apps should still work and it's only a 5X slowdown for long-running JS with yields.

Comment 8

[Anthony Ricaud (:rik)]

I think this is now a dupe of bug 633421, which has a patch.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Ah, indeed.  I forgot that I filed this once already...