Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=364538819208b8d875e54d344359d3941c73ee59 As author of one of the patches included in that push, we need your help to address this regression. Regressions: 13% tp5o responsiveness windows7-32 pgo e10s 3.27 -> 3.70 Improvements: 7% tsvg_static summary windows7-32 pgo e10s 57.54 -> 53.43 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=8444 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
:till I see you are the owner of bug 1272697's latest changes. Please look over this tp5o performance regression. Can you estimate a fix time for it?
2 years ago
Product: Firefox → Core
(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #1) > :till I see you are the owner of bug 1272697's latest changes. Please look > over this tp5o performance regression. > Can you estimate a fix time for it? I don't think there's a fix to apply here. The only way I can interpret these numbers is that the additional code for ReadableStream changed internal heuristics MSVC uses for PGO builds. In part I'm convinced of this because otherwise it'd make no sense whatsoever for tsvg to *improve* by 7%. Note also that ReadableStream is disabled by default, so the only three differences the landing introduced are: - A few 1000 lines of C++ code. - A runtime flag transmitted to the JS engine. - A check of said runtime flag during creation of JS globals. I should note that the last two items are identical to preexisting checks for other JS features, notably WebAssembly support. (Except that is enabled by default.)
The equivalent OPT build does sustain what you are saying, as it doesn't record higher tp5o test values.
I vote for closing this as wontfix (as this is a pgo artifact)
I concur, there's nothing actionable here.
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.