Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Javascript performance when running in an unfocused tab

It seems like there has been a change to some recent version of Chrome and Firefox*, and now Javascript execution seems to be different when the tab it is being run in is not the currently focused one.

When I run my Javascript unit tests, they normally take about 20 seconds to complete but now, when the tab is unfocused, it takes upwards of 2000 seconds. What is strange though, is that the run times for each individual test are not affected (most are still < 10ms). The test runner I'm using adds a setTimeout(0) between running each test so that the browser doesn't lock up while executing, and so that seems the likely culprit.

Is there a way to tell the Javascript engine not to "deprioritise" that tab though? It's nice to be able to run my tests in the background without having to watch myself...

*sorry, I don't really care enough to try installing old versions to find when this started happening. At the very least, it's happening now on Firefox 5.0 and Chrome 12.

like image 300
nickf Avatar asked Jul 05 '11 15:07

nickf


3 Answers

setTimeout and setInterval have been throttled to a minimum of 1000ms in unfocused tabs. Here is the Bugzilla report that mentions it. And here is the similar Chromium bug report. I believe this is the case in Firefox 5 and in Chrome since version 11.

According to MDN:

In (Firefox 5.0 / Thunderbird 5.0) and Chrome 11, timeouts are clamped to firing no more often than once per second (1000ms) in inactive tabs; see bug 633421 for more information about this in Mozilla or crbug.com/66078 for details about this in Chrome.

As for getting around this restriction, you could try the technique discussed in this article, but I haven't had a change to try it myself yet.

like image 182
James Allardice Avatar answered Nov 17 '22 21:11

James Allardice


For Firefox in particular, you can change the dom.min_background_timeout_value preference in about:config to a number of your liking in the profile that you use to run the tests. I wouldn't suggest doing that in your default browsing profile, though: the reason for the high clamp is that it cuts down on web sites in background tabs chewing up CPU updating silly tickers and the like.

like image 43
Boris Zbarsky Avatar answered Nov 17 '22 21:11

Boris Zbarsky


The change made was to increase (by a lot) the minimum timeout value. To my knowledge there's no way to control that; it's in the innards of the timer implementation. Both Chrome and Firefox do this now, maybe Safari too.

It gets pretty weird if you use "setInterval()", because it seems that the browser wants to make sure that the interval callback gets called the proper number of times. When you return to the page, you get a burst of activity from the interval timers as they catch up.

like image 2
Pointy Avatar answered Nov 17 '22 20:11

Pointy