3.28 - 4.65% sessionrestore / startup_about_home_paint (linux64-shippable, windows10-64-shippable, windows10-64-shippable-qr) regression on push 6534d80a3329536b4bb9068f9d56ccb030616750 (Fri Apr 12 2019)
Categories
(Firefox :: Search, defect, P3)
Tracking
()
Performance Impact | medium |
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | wontfix |
firefox69 | --- | wontfix |
firefox70 | --- | wontfix |
firefox71 | --- | fix-optional |
People
(Reporter: Bebe, Unassigned)
References
(Depends on 1 open bug, Regression)
Details
(5 keywords, Whiteboard: [memshrink:P2])
Talos has detected a Firefox performance regression from push:
As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
5% sessionrestore windows10-64-shippable opt e10s stylo 456.04 -> 477.25
4% sessionrestore windows10-64-shippable-qr opt e10s stylo 472.67 -> 492.75
4% sessionrestore windows10-64-shippable opt e10s stylo 458.67 -> 477.42
3% startup_about_home_paint windows10-64-shippable opt e10s stylo 610.92 -> 631.50
3% sessionrestore linux64-shippable opt e10s stylo 496.17 -> 512.42
You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=20464
On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.
To learn more about the regressing test(s), please see: https://wiki.mozilla.org/Performance_sheriffing/Talos/Tests
For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/Performance_sheriffing/Talos/Running
*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***
Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/Performance_sheriffing/Talos/RegressionBugsHandling
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
This caused a regression on awsy
== Change summary for alert #20465 (as of Mon, 15 Apr 2019 06:13:34 GMT) ==
Regressions:
2% Base Content Heap Unclassified windows10-64-shippable-qr opt 1,577,693.00 -> 1,615,288.00
2% Base Content Heap Unclassified windows10-64-shippable-qr opt 1,577,869.33 -> 1,613,768.67
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=20465
Updated•6 years ago
|
Updated•6 years ago
|
Comment 3•6 years ago
|
||
We think the regressions here are probably a result of add-on manager reading a lot of extra files on startup (from omni.ja) due to the switch of Search Engines to WebExtensions - see bug 1529321.
Although, if anyone can confirm that from the profiles, that would be useful.
Note that bug 1529321 comment 7 indicates that fixing the add-on manager would be a lot of work.
Comment 4•6 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #3)
We think the regressions here are probably a result of add-on manager reading a lot of extra files on startup (from omni.ja) due to the switch of Search Engines to WebExtensions - see bug 1529321.
This is quite unlikely to be the case. The overhead described in bug 1529321 only occurs when an extension is first installed which happens in the first run in a new profile, but not in subsequent runs in the same profile. For better or worse, Talos deliberately discards any measurements from its first run to eliminate effects that are specific to the first startup in a new profile.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Florin, this was opened 7 months ago. Is this still a problem? Marking this as p2 since any memory regression is a bigger concern with fission coming up.
Reporter | ||
Comment 6•5 years ago
|
||
Any regression is a "problem" and should be fixed.
We need to update and work on a fix as this is a old regression from Firefox 68
I agree with updating the priority as P2
Updated•5 years ago
|
Comment 7•3 years ago
|
||
Hi, I think that this bug is no longer valid in the face of the latest changes on the browser. If I'm mistaken, please reopen it.
Regards, Flor.
Comment 8•3 years ago
|
||
(In reply to Florencia Di Ciocco, QA from comment #7)
Hi, I think that this bug is no longer valid in the face of the latest changes on the browser. If I'm mistaken, please reopen it.
I wouldn't say it's no longer valid, but considering the amount of time that's passed without any action we can accept the regression.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•