Closed Bug 1380385 Opened 2 years ago Closed 2 years ago
.84 - 4 .85% damp (linux64) regression on push dbcc5752dea8 (Tue Jul 11 2017)
Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=dbcc5752dea8 As author of one of the patches included in that push, we need your help to address this regression. Regressions: 5% damp summary linux64 pgo e10s 201.20 -> 210.97 4% damp summary linux64 opt e10s 228.26 -> 237.03 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=7864 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/Buildbot/Talos/Tests For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/Buildbot/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/Buildbot/Talos/RegressionBugsHandling
I did some retriggers to hunt this down and it looks like this is a clear regression here: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e897b12b2b63ef95ce8c7ee3fb2c867457d5c1d7&tochange=dbcc5752dea8e54ed33c35a07eec42800b69cfb0 :gabor, I see you authored the patch for bug 1373660, can you take a look at this regression and determine if there is something that can be done to fix this or if we should accept this?
Component: Untriaged → DOM: Content Processes
Product: Firefox → Core
I think we just have to swallow this :( The benefit of the patch in bug 1373660 outweighs this regression. We still need to juggle with the price of starting up an extra content process unfortunately and that patch makes sure that we're more careful about when to start a preallocated process in the background, which is great for most cases (for user perceived performance in general). Probably with some tuning on the test I could make this regression go away (waiting a bit before the test to give a chance for the preallocated process to start up in the background). I might look into that... By the way, I overheard it during the allhands that we might want to get rid of this test (damp) entirely (or break it up / rewrite it), is that option on the table realistically?
I am not aware of changes for damp, I know :bgrins wrote that originally- from my point of view I don't see anything wrong with modifying the test, splitting it up, or stop running it, this is a test for the devtools team and it would be their decision. Thanks for the good information about this bug :gabor, I think we should resolve this as wontfix and move on, feel free to do that.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.