Closed Bug 1388645 Opened 7 years ago Closed 7 years ago

4610.4 - 6511.59% tp5n nonmain_startup_fileio (windows7-32) regression on push cb33a188655b840e499497e617cfe05085a5c382 (Wed Aug 9 2017)

Categories

(Core :: Widget: Win32, defect)

Unspecified
Windows
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: igoldan, Unassigned)

References

Details

(Keywords: perf, regression, talos-regression)

Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=cb33a188655b840e499497e617cfe05085a5c382

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

6512%  tp5n nonmain_startup_fileio windows7-32 opt e10s     23,140.58 -> 1,529,959.77
4610%  tp5n nonmain_startup_fileio windows7-32 pgo e10s     32,592.58 -> 1,535,242.17


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=8650

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
Adam, I see you are the owner of bug 1367416. This is a big startup regression. Can we improve on it now or should we rather backout?
Flags: needinfo?(agashlin)
If I understand correctly from the name "nonmain_startup_fileio", this is measuring precisely where bug 1367416 is offloading work, doing I/O on a background thread ahead of it being needed by the main thread. Who should I contact to discuss whether this regression should be allowed?

I also noticed that main thread I/O is also significantly up (200-300KB, vs the 1.5MB added to nonmain), this is more concerning to me as I would not expect that from my patch.

https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=autoland&newRevision=cb33a188655b840e499497e617cfe05085a5c382&framework=1&showOnlyImportant=0&showOnlyConfident=1&selectedTimeRange=172800
Flags: needinfo?(agashlin)
(In reply to Adam Gashlin [:agashlin] from comment #2)
> If I understand correctly from the name "nonmain_startup_fileio", this is
> measuring precisely where bug 1367416 is offloading work, doing I/O on a
> background thread ahead of it being needed by the main thread. Who should I
> contact to discuss whether this regression should be allowed?
> 

I think you've more or less just justified it. This sounds like an expected "regression", with the trade-off being that we get (presumably) faster access to some libraries when they are accessed on the main thread. If this were the only thing here, I'd recommend we just WONTFIX this.

Not sure what to do about the main thread IO increase. You could attempt some before/after try pushes with MOZ_MAIN_THREAD_IO_LOG set to see if that illuminates anything.
Thanks, I tried MOZ_MAIN_THREAD_IO_LOG locally and didn't find anything significant. I tried setting it on a try push [1] but I don't see any way to get access to the created log, is there a particular file I have to direct it to?

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=476743aa164bda35779f99ce7a3c05b8570f75f9&selectedJob=122048210
Component: Untriaged → Widget: Win32
Product: Firefox → Core
Flags: needinfo?(mconley)
I think I misinterpreted the perfherder compare results, looking at the graph main_startup_fileio increased a few revisions before my patch hit autoland:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=604800&series=%5Bautoland,f5df38aff6d94ef9ffdaea648fd465fb0249bf1f,1,1%5D&highlightedRevisions=cb33a188655b&highlightAlerts=0&zoom=1502202147374.3843,1502256346086.2068,68500000,69544776.11940299


I ran try directly comparing xperf with and without the patch, before:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=980829eb8e559409def9cc25c90803d84cf934ca&selectedJob=122336684

after:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=be5a7127a00460af641a5e4c95a8b5c23bb25396&selectedJob=122326628

This seems to verify there is no impact on main_startup_fileio, so there is now nothing unexpected in the xperf results to my knowledge.

Therefore I agree with mconley on WONTFIX.
\o/
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mconley)
Resolution: --- → WONTFIX
Great! Thanks for the detailed explanations and for resolving this.
You need to log in before you can comment on or make changes to this bug.