Closed Bug 1377766 Opened 7 years ago Closed 6 years ago

Enable budget throttling by default


(Core :: DOM: Core & HTML, enhancement, P2)




Tracking Status
firefox58 --- fixed


(Reporter: farre, Assigned: farre)


(Depends on 1 open bug)


(Keywords: dev-doc-complete)


(1 file)

      No description provided.
Assignee: nobody → afarre
Depends on: 1362322
Depends on: 1378123
Depends on: 1378124
Depends on: 1378125
Depends on: 1378356
Depends on: 1378402
As expected there are loads of oranges if this is turned on:

Haven't checked all (there are 500+ failures), but those I did check were of the test timed out variety.
Depends on: 1384917
Depends on: 1384924
Depends on: 1385238
Depends on: 1391602
Depends on: 1393056
Depends on: 1393359
Depends on: 1393764
(P2 only because we're going to try to ship it soon but it's not a super-critical crasher or something like that :)
Priority: -- → P2
Are there plans to use different timeout values on Android given that currently background timeouts are much more heavily throttled there? (
See Also: → 1404042
Attachment #8916574 - Flags: review?(bkelly) → review+
Keywords: checkin-needed
Pushed by
Enable budget throttling by default. r=bkelly
Keywords: checkin-needed
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Depends on: 1407207
Keywords: dev-doc-needed
Key word "perf"?
I've started documenting this by adding a section to the Page Visibility API landing page to explain the policies we have in place to mitigate perceived background performance problems:

I thought this seemed like OK place to put it.

To help with this, can you:

1. Let me know if you think this place is ok.
2. Let me know what the effects of Budget based background timeout throttling are — do we follow the same policy as Chrome, e.g. , or something else?

Once I know this, I'll fill out that section, and add a note to the Fx58 rel notes.

Flags: needinfo?(afarre)
It looks like the perfect place. 

We follow a /similar/ policy, matching all bullets from we behave as follows:

* Windows in each background tab in the background has a time budget in milliseconds

Not sure if this differs in that Chrome has per tab where we have per window. Our budget is in milliseconds with a max and a min value +50 ms, -150 ms respectively.

* Windows are subjected to throttling after 30 seconds, mainly because we re-use the throttling delay from Bug 1355311.

This has been manually tested, but is a bit hand-wavey.

* Timer tasks are indeed only allowed when the budget is non-negative.

* When a timer has executed, the execution time is deducted from the budget from the window where the timeout gets called from.

* Budget regenerates at the same rate, 10 ms per second. 

The exceptions from throttling are the same. We also add IndexedDB to the list of exceptions, mainly due to, but now when checking Chrome seems to throttle even when there are active IndexedDB transactions. Also, we differ from Chrome in that Chrome stops throttling pages with audio, and will not start throttling again when audio stops playing.

For the curious here's the toy I wrote and put here: The UI is a bit messy, but just hit the 'Run Test' button and wait to see the throttling behaviour of the UA.
Flags: needinfo?(afarre)
Sorry, that Chromium issue regarding IndexedDB is not relevant. Regardless, I'm fairly certain that Chrome also used to limit throttling of IndexedDB to once per second, but not with budget. Will check this some more tomorrow.
(In reply to Worcester12345 from comment #9)
> Key word "perf"?

So this wasn't a performance fixing bug then?
Cool, thanks a lot for the notes Andreas! I have filled in those details on the page mentioned:

I have also added a note to the Fx 58 rel notes:

Please let me know if you think the section needs any more information, or fixes.
Flags: needinfo?(afarre)
Looks excellent!
Flags: needinfo?(afarre)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.