2.29 - 3.18% Explicit Memory (windows7-32, windows7-32-shippable) regression on push 3a083701018bf872acfc5e391312042d8d246aa4 (Wed December 4 2019)
Categories
(Core :: Graphics, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox71 | --- | unaffected |
firefox72 | --- | unaffected |
firefox73 | --- | disabled |
firefox74 | --- | disabled |
firefox75 | --- | fix-optional |
People
(Reporter: alexandrui, Unassigned)
References
(Regression)
Details
(Keywords: perf, perf-alert, regression)
We have detected an awsy regression from push:
As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
3% Explicit Memory windows7-32-shippable opt 292,050,017.04 -> 301,342,667.60
3% Explicit Memory windows7-32 opt 292,771,546.53 -> 300,284,872.30
2% Explicit Memory windows7-32 opt 292,529,978.24 -> 299,596,814.31
2% Explicit Memory windows7-32 opt 293,403,644.06 -> 300,135,796.56
You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=24471
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 jobs in a pushlog format.
To learn more about the regressing test(s), please see: https://wiki.mozilla.org/AWSY/Tests
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
It looks like the same as bug 1584101 that happened the last time we enabled the feature, the fixes there should have helped, but apparently they didn't.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #1)
It looks like the same as bug 1584101 that happened the last time we enabled the feature, the fixes there should have helped, but apparently they didn't.
They did, I confirmed on Try before landing and post-landing improvements were noted in the bug.
Comment 3•5 years ago
|
||
looking at sub tests, the regression is on tabs closed, and afaict from comparing the memory logs, the difference is still in
8.50 MB (112.91%) ── gfx/heap-textures
Comment 4•5 years ago
|
||
Seems like we need to go back in time on Try to figure out if and when this regressed again.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 6•5 years ago
|
||
I'll investigate this.
We don't need to track this for 73 because the megabar currently targets 74, that is, it won't merge to beta 73.
Updated•5 years ago
|
Comment 7•5 years ago
|
||
Hi Dao, is the megabar still targeting 74? And who's working on it?
Comment 8•5 years ago
•
|
||
(In reply to Ethan Tseng [:ethan] from comment #7)
Hi Dao, is the megabar still targeting 74?
Potentially.
And who's working on it?
I've been investigating this but don't have a definite solution yet.
Bug 1584101's patch is working in the sense that we set and remove the urlbar-exceeds-toolbar-bounds
attribute as expected. That is, we set it when focusing the address bar (because it then renders outside the toolbar) and remove it when removing focus. With the megabar design disabled, we only set this attribute when opening the results panel, not when merely focusing the address bar. When bug 1584101's patch landed, the megabar design was temporarily disabled and the regression went away. Now with the megabar enabled, the regression is back.
I think this means that either AWSY finishes with the address bar focused or Gecko reserves that texture despite the fact that we set overflow: -moz-hidden-unscrollable;
on the toolbar after unfocusing the address bar. Timothy or Matt, is the latter theory plausible and is this something that could be fixed on the Gecko side?
Updated•5 years ago
|
Comment 9•5 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #8)
I think this means that either AWSY finishes with the address bar focused or Gecko reserves that texture despite the fact that we set
overflow: -moz-hidden-unscrollable;
on the toolbar after unfocusing the address bar. Timothy or Matt, is the latter theory plausible and is this something that could be fixed on the Gecko side?
It's not obvious how it would (but hard to reason about given multiple backgrounds). We should be clipping everything to the bound rect when -moz-hidden-unscrollable is present.
Comment 10•5 years ago
|
||
I guess we finish the test with the address bar focused then. Alexandru, how can I run this test locally?
Reporter | ||
Comment 11•5 years ago
|
||
Dao, I don't know. Maybe it's worth asking Drew.
Comment 12•5 years ago
|
||
Standard8 told me it's ./mach awsy-test
but that takes way too long to run. Luckily there's ./mach awsy-test --quick
. Based on this I can say that the address bar is only focused at the very beginning of the test. I also checked that the urlbar-exceeds-toolbar-bounds
attribute is not set on the toolbar at the end of the test.
Now I'm looking again at the subtests:
https://treeherder.mozilla.org/perf.html#/comparesubtest?framework=4&originalProject=autoland&originalSignature=2118213&newProject=autoland&newSignature=2118213&originalRevision=bcedfb13f4b2591a811e4dd693c479218e2cd24c&newRevision=3a083701018bf872acfc5e391312042d8d246aa4
The alert is for Tabs closed
, but the regression is already there for After tabs open
, it's just relatively smaller. Ironically, there doesn't seem to be a regression for Fresh start
which is when the address bar is or just had been focused.
I'm not sure where to go from here, but I still suspect that in the end this is either a graphics bug or just invalid (i.e. it's expected that the toolbar using a larger texture at the beginning of the test somehow affects the above subtests). I'll move this to Core::Graphics for now. :/
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
Comment 13•3 months ago
|
||
Hi :dao, I'm closing this as WONTFIX based on comment #12. Furthermore, we don't test on windows 7 anymore so it could be difficult to reproduce this. Feel free to change this if needed.
Comment 14•3 months ago
|
||
If there was still a problem here, bug 1921811 likely solved this problem by changing the front-end implementation to using the newish popover API.
Description
•