Disable privileged content process on Nightly for now
Categories
(Core :: DOM: Content Processes, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | fixed |
People
(Reporter: mconley, Assigned: mconley)
References
Details
Attachments
(1 file)
There are a number of things preventing us from having about:home load in the privileged content process by default for now - see bug 1513045 for a list of blockers.
In the interests of testing what we ship, we should probably just disable it until DOM has finished up moving the process switching stuff out of JS.
|
Assignee | |
Comment 1•5 years ago
|
||
We've had this enabled and holding on Nightly for a while now, but
it's not been able to ride the trains due to a number of issues.
In the interests of testing what we ship, we should disable it until
it's closer to being ready to ship.
|
||
Updated•5 years ago
|
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
||
Comment 4•5 years ago
|
||
Could this change be responsible for a sudden decrease in the number of samples (and a decrease in the values of the samples still being reported) for the Scalar contentprocess.os_priority_raised? It showed a Telemetry alert: http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/2892/alerts/?from=2019-08-16&to=2019-08-16
This bug may have contributed to a sudden change in the Telemetry scalar contentprocess.os_priority_raised1 which seems to have occurred in Nightly 201908162.
There was a decrease in the number of samples and in the value of samples that are reported.
This might mean many more subsessions have 0 processes with their priority raised, and the ones that have more than 0 have fewer now than before.
Is this an improvement? A regression?
Is this intentional? Is this expected?
Is this probe still measuring something useful?
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 5•5 years ago
|
||
(In reply to Chris H-C :chutten from comment #4)
Could this change be responsible for a sudden decrease in the number of samples (and a decrease in the values of the samples still being reported) for the Scalar
contentprocess.os_priority_raised? It showed a Telemetry alert: http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/2892/alerts/?from=2019-08-16&to=2019-08-16
Yes, I believe this change is responsible for the shift in the histograms.
Is this an improvement? A regression?
This is neither - by disabling the privileged about content process for about:home, we've reduced the number of content processes that are being opened by default.
We're also preventing preloaded about:newtab's from loading in that privileged about content process, which I think is the bigger factor here: before this patch landed, if a user had no about:newtab / about:home tabs in the foreground, we'd kick off an idle task that would preload the next about:newtab in the privileged about content process, and because the preloaded about:newtab is hidden in the background, that privileged about content process would have its priority lowered, and then raised as soon as the next about:newtab was opened.
With the privileged about content process disabled, the default behaviour is to preload the next about:newtab by attaching to a pre-existing content process. There's a higher likelihood that the pre-existing content process is already in the foreground and won't need to have its process priority shifted when the user opens that about:newtab.
Is this intentional? Is this expected?
I had forgotten these probes existed, but upon reflection, I think what happened here makes sense.
Is this probe still measuring something useful?
Yes, I believe so.
|
||
Comment 6•5 years ago
|
||
== Change summary for alert #22890 (as of Thu, 29 Aug 2019 15:16:28 GMT) ==
Improvements:
10% raptor-tp6-yahoo-mail-firefox loadtime windows10-64-shippable opt 469.00 -> 424.00
5% raptor-tp6-yahoo-mail-firefox windows10-64-shippable opt 316.96 -> 302.13
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=22890
Description
•