1380406 - 3.86 - 8.23% Explicit Memory / Heap Unclassified / JS / Resident Memory (windows10-64-vm, windows7-32-vm) regression on push a625a2e9b3333a8e76982ea65f077cfded6ac224 (Sat Jul 8 2017)

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect, P1)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

We have detected an awsy regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=a625a2e9b3333a8e76982ea65f077cfded6ac224

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

Regressions:

  8%  JS summary windows7-32-vm opt      90,584,556.60 -> 98,040,740.43
  8%  Heap Unclassified summary windows7-32-vm opt 40,562,028.99 -> 43,878,926.75
  7%  Explicit Memory summary windows7-32-vm opt 239,786,528.45 -> 257,272,895.42
  7%  JS summary windows10-64-vm opt     122,901,159.70 -> 131,275,579.21
  6%  Heap Unclassified summary windows10-64-vm opt 46,073,281.26 -> 49,004,416.22
  6%  Explicit Memory summary windows10-64-vm opt 303,093,133.14 -> 321,915,699.74
  5%  Resident Memory summary windows7-32-vm opt 298,107,050.72 -> 313,012,301.59
  4%  Resident Memory summary windows10-64-vm opt 467,925,691.15 -> 485,969,132.08


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

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://developer.mozilla.org/en-US/docs/Mozilla/Performance/AWSY

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

:kmag, I know I mentioned in bug 1357486 that you had some perf wins, but there are some memory regressions- are these expected?

Comment 2

[Kris Maglione [:kmag]]

If these numbers are across all processes, then yes, this is expected. The addition of an extra content process to host WebExtension code should cause an increase in memory consumption.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

I assume that is the case, :erahm, does AWSY collect memory from all processes, even new ones that?

Comment 4

[Eric Rahm [:erahm]]

(In reply to Joel Maher ( :jmaher) (UTC-8) from comment #3)
> I assume that is the case, :erahm, does AWSY collect memory from all
> processes, even new ones that?

Yeah if it's just a content process. The GPU process had to opt-in, I'm not 100% sure about the web extension process, but I think it's just another content process.

Comment 5

[Kris Maglione [:kmag]]

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #4)
> (In reply to Joel Maher ( :jmaher) (UTC-8) from comment #3)
> > I assume that is the case, :erahm, does AWSY collect memory from all
> > processes, even new ones that?
> 
> Yeah if it's just a content process. The GPU process had to opt-in, I'm not
> 100% sure about the web extension process, but I think it's just another
> content process.

For the most part, yes, it's a normal content process. It has a different remoteType, but the actual process type is PROCESS_TYPE_CONTENT.

Comment 6

[Ionuț Goldan [:igoldan]]

(In reply to Kris Maglione [:kmag] from comment #2)
> If these numbers are across all processes, then yes, this is expected. The
> addition of an extra content process to host WebExtension code should cause
> an increase in memory consumption.

Then I will mark this bug as WONTFIX, if you all agree.

Comment 7

[Kris Maglione [:kmag]]

Yes, agreed. We still need to work on decreasing our content process memory overhead, but adding a new content process is always going to cause some significant memory overhead. And running extensions in a separate process is an important part of our Quantum release criteria, so that's the trade-off we're going to have to make for now.