Closed Bug 1248366 Opened 9 years ago Closed 9 years ago

2.49 - 2.95% damp e10s (linux64, windows7) regression on fx-team (v.47) from push cb04e167e1df (Wed Feb 10 2016)


(DevTools :: Framework, defect)

Not set


(e10s+, firefox47 fixed)

Firefox 47
Tracking Status
e10s + ---
firefox47 --- fixed


(Reporter: jmaher, Assigned: ochameau)



(Keywords: perf, regression, Whiteboard: [talos_regression])

Talos has detected a Firefox performance regression from push cb04e167e1df. As author of one of the patches included in that push, we need your help to address this regression.

This is a list of all known regressions and improvements related to the push:

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:

Reproducing and debugging the regression:

If you would like to re-run this Talos test on a potential fix, use try with the following syntax:
try: -b o -p linux64,win32 -u none -t g2-e10s[Windows 7] --rebuild 5  # add "mozharness: --spsProfile" to generate profile data
(we suggest --rebuild 5 to be more confident in the results)

To run the test locally and do a more in-depth investigation, first set up a local Talos environment:

Then run the following command from the directory where you set up Talos:
talos --develop -e <path>/firefox -a damp --e10s

Making a decision:
As the patch author we need your feedback to help us handle this regression.
*** Please let us know your plans by Thursday, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:</path>
I have done a lot of retriggers on the tree to collect more data:

more data is coming in still, but here is a compare view to reference the regressions;

clicking on the subtests ^ for linux64, the .close methods are taking a big hit.

:ochameau, can you take a look at this bug and help us get this resolved?
Flags: needinfo?(poirot.alex)
In bug 1188405, I'm introducing a compatibility wrapper in gDevTools.jsm.
This wrapper is most likely slower.
But I landed in bug 1245462, a significant refactoring to bypass this compatibility wrapper.
So that I'm expecting performance to be equivalent between before bug 1188405 and after bug 1245462.
It shouldn't be much better of worse before/after these two patches.

Is there a way to do a Talos run before bug 1188405 and after 1245462?
Or to be very sure of what I'm saying: with 1188405 and a cherry-pick of bug 1245462 on top of it?

Longer story:
Devtools were using gDevTools.jsm. A JSM module.
This module has been split into two common js module, loaded via the devtools loader (Loader.jsm).
In bug 1188405, I just did that. And I kept gDevTools.jsm. In order to keep it working, I added some wrapper that will automatically call one of the two common js modules. This add a layer of function and I can easily understand some performance hit.
In bug 1245462, I refactored all the codebase to load the two common js modules directly, so that there shouldn't be any additional wrapper.
Flags: needinfo?(poirot.alex)
Flags: needinfo?(poirot.alex)
Yes. I don't think it is worth investigating it.
We can easily see numbers getting back to normal on Feb 11, when bug 1245462 reached fx-team.[fx-team,e8783606b9fae730f8511d1e1e6f5ad6a5130be2,1]&highlightedRevisions=cb04e167e1df

But this is great to hear that DAMP is able to track such possible regression!
Closed: 9 years ago
Flags: needinfo?(poirot.alex)
Resolution: --- → FIXED
Assignee: nobody → poirot.alex
Depends on: 1245462
Target Milestone: --- → Firefox 47
Version: unspecified → Trunk
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.