stylo: causes memory consumption to double for gmail

VERIFIED FIXED

Status

()

P3
normal
VERIFIED FIXED
a year ago
a year ago

People

(Reporter: linuxhippy, Unassigned)

Tracking

(Depends on: 1 bug, {memory-footprint, nightly-community})

56 Branch
memory-footprint, nightly-community
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fixed)

Details

Attachments

(7 attachments)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170819205558

Steps to reproduce:

1. enabled stylo/servo: layout.css.servo.enabled -> true
2. restarted firefox
3. opened my (quite large) gmail inbox


Actual results:

with stylo/servo enabled, the WebContent Process consumes twice the memory compared to before enabling servo (only 1 gmail tab open!):

PID      USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND  
13715 ce        20   0 2805724 659432 132376 S  86.4 11.2   0:20.38 firefox-bin                                                
13793 ce        20   0 2988672 845312 121472 R  19.9 14.3   0:18.94 Web Content   




Expected results:

servo/stylo should use aprox. the same amount of RAM for gmail than the old implmentation.
Component: Untriaged → CSS Parsing and Computation
Keywords: footprint
Product: Firefox → Core
Blocks: 1375906
Keywords: nightly-community
Summary: Servo/stylo causes memory consumption to double for gmail → stylo: causes memory consumption to double for gmail
Could you post both about:memory, with and without stylo? Thanks!
Flags: needinfo?(linuxhippy)
"Firefox/56.0" - So you are using Beta?
If I'm not wrong, all recent optimizations were done in Nightly 57 and not uplifted to Beta 56.
Could you check if https://nightly.mozilla.org is better?
A couple of questions:

1) Are these measurements with a clean (preferably an entirely new) profile?
2) Have you looked at about:memory numbers for the two use cases?  If you could provide those as well, that would be most helpful.
3) Can you provide actual numbers for the Web Content process without stylo enabled?  There are several memory-related numbers in the above, and it's not clear which ones you're referencing.
4) Did you try to ensure that both processes were in a comparable state before measuring memory?
Created attachment 8899661 [details]
gecko-on-gmail.json.gz

about:memory measure saved on conditions that stylo is off and load gmail inbox with a clean profile.

Web Content process memory usage is around 190MB.
Created attachment 8899662 [details]
stylo-on-gmail.json.gz

about:memory measure saved on conditions that stylo is *ON* and load gmail inbox with a clean profile.

Web Content process memory usage is around ~240~250MB in several attempts.
The data was collected from Nightly 57.0a1 (2017-08-20) (64-bit) on macOS 10.12.6.
Status: UNCONFIRMED → NEW
Ever confirmed: true
There is also a stylo meta bug 1293767 which is chiefly tracking on memory footprint issues.
It would make sense to me to track the bugs akin at one place.
This is another one possibly related to bug 1367854. Boris and Cameron are going to have a look.
No longer blocks: 1375906
Depends on: 1367854
Flags: needinfo?(bzbarsky)
Priority: -- → P3
(Marking P3 for now until we know whether it's distinct from the work in bug 1367854).
Created attachment 8905330 [details]
Gmail about:memory, no stylo
Flags: needinfo?(bzbarsky)
Created attachment 8905331 [details]
Gmail about:memory, STYLO_THREADS=1
Created attachment 8905332 [details]
Gmail about:memory, STYLO_THREADS=3
Created attachment 8905333 [details]
Gmail about:memory, STYLO_THREADS=6
Comparing those stylo about:memory logs to the no-stylo one, I see a 23MB increase on a 209MB baseline from no-stylo to 3-threads stylo.  The diff is a bit confusing to read because the urls of the various hangouts junk gmail loads keep changing, but the upshot is that "style-sheets" is smaller with servo, and servo-style-sets is smaller than gecko-style-sets.  servo-style-structs is 2x larger than gecko-style-structs there, but that's a difference between 400KB and 800KB, which is not much.  Similarly, servo computed-value is 0.34MB vs Gecko style-contexts at 0.11MB, but that's pretty minor.

The big difference is the 38MB increase in heap-unclassified from Gecko to stylo.  Going to look at DMD bits.
Created attachment 8905338 [details]
Gzipped dmd diff output for non-stylo vs stylo (probably with 12 threads, in case it matters) on gmail
OK, so looking at the DMD output we have:

1) At least 5MB coming from background::parse_value doubling vecs.
2) At least 1.5MB directly from QualifiedRuleParser::parse_block.
3) At least 1.3MB from PropertyDeclarationBlock::extend_common reserving space in a vec.

etc, etc.  It all looks like stylesheet data, in my poking at it so far.  I thought we had memory reporting for the servo stylesheets...  I guess njn was just poking at this and discovering that grouping rules are not reported well; maybe that's what's going on...
> 3) At least 1.3MB from PropertyDeclarationBlock::extend_common reserving
> space in a vec.

I think https://github.com/servo/servo/pull/18400 will help with this, because it adds measurement of PageRule::block.
Depends on: 1397614
> 1) At least 5MB coming from background::parse_value doubling vecs.

My measurements gave more like 11 MiB, or even more. https://github.com/servo/servo/pull/18404 is measuring this.
No longer depends on: 1397614
Depends on: 1397971
Depends on: 1398322
OK.  On current tip, but not including the fix for bug 1398322, I see numbers like so:

stylo:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 6562 bzbarsky  20   0 2469176 416200 136396 S   2.3  1.3   0:06.01 Web Content
 6491 bzbarsky  20   0 2185912 286176 132328 S   1.3  0.9   0:03.62 firefox

non-stylo:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 6776 bzbarsky  20   0 2432680 422096 132684 S  63.9  1.3   0:04.85 Web Content
 6705 bzbarsky  20   0 2194064 286012 128152 S  21.2  0.9   0:03.01 firefox

so I think this is fixed at this point; we're about at parity on gmail.

Clemens, do you want to confirm on your end, probably in tomorrow's nightly, once all these pieces merge to m-c?
Optimistically resolving fix. Clemens, please set VERIFIED when you test.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
(Reporter)

Comment 21

a year ago
Thanks for fixing this issue :)
Flags: needinfo?(linuxhippy)
(Reporter)

Updated

a year ago
Status: RESOLVED → VERIFIED
Depends on: 1400100
status-firefox57: --- → fixed
You need to log in before you can comment on or make changes to this bug.