Project Fission/Memory: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (→‎AWSY (sb): fix link)
(Add details on test with awsy)
Line 17: Line 17:
Our main focus for Fission is the simpler about:blank ''SY-e10s(ab)'' test. This gives a less noisy baseline metric that allows us to focus on incremental improvements. This is essentially our ''best case'' metric.
Our main focus for Fission is the simpler about:blank ''SY-e10s(ab)'' test. This gives a less noisy baseline metric that allows us to focus on incremental improvements. This is essentially our ''best case'' metric.


===== Metrics =====
'''Resident Unique''' is our main measurement of success. It's the total amount of memory that the content process is using that's not shared with other processes:
'''Resident Unique''' is our main measurement of success. It's the total amount of memory that the content process is using that's not shared with other processes:
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1684862,1,4 Resident Unique Memory - Linux]
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1684862,1,4 Resident Unique Memory - Linux]
Line 27: Line 28:
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1684850,1,4 JavaScript Memory - OSX]
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1684850,1,4 JavaScript Memory - OSX]
* [https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-central,1684866,1,4&series=autoland,1684884,1,4&series=mozilla-inbound,1684802,1,4&zoom=1541470622441.3396,1541636058000,4522136.655023917,4592343.839863093 JavaScript Memory - Regression view]<br/>This is useful for tracking down where a regression started by breaking out integration branches. It's limited to just Linux, but JS is generally platform agnostic.
* [https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-central,1684866,1,4&series=autoland,1684884,1,4&series=mozilla-inbound,1684802,1,4&zoom=1541470622441.3396,1541636058000,4522136.655023917,4592343.839863093 JavaScript Memory - Regression view]<br/>This is useful for tracking down where a regression started by breaking out integration branches. It's limited to just Linux, but JS is generally platform agnostic.
===== Testing your changes =====
To run locally use:
./mach awsy-test testing/awsy/awsy/test_base_memory_usage.py
To run on try for comparisons use:
hg up base_revision
./mach try -b o -p linux64 -u awsy-base-e10s -t none --rebuild 5
hg up new_revision
./mach try -b o -p linux64 -u awsy-base-e10s -t none --rebuild 5


==== AWSY (sy) ====
==== AWSY (sy) ====
The original test suite, ''SY-e10s(sy)'', is a stress test that loads 100 pages into 30 tabs 3 times and measures memory at various points and is useful for detecting regressions in startup memory usage, longer term leaks, leaked windows, etc. This is essentially our ''worst case'' metric.
The original test suite, ''SY-e10s(sy)'', is a stress test that loads 100 pages into 30 tabs 3 times and measures memory at various points and is useful for detecting regressions in startup memory usage, longer term leaks, leaked windows, etc. This is essentially our ''worst case'' metric.


===== Metrics =====
'''after tabs opened''' is one of several data points gathered, it is the most relevant to this project:
'''after tabs opened''' is one of several data points gathered, it is the most relevant to this project:
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1651963,1,4 Resident Memory - Linux]
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1651963,1,4 Resident Memory - Linux]
Line 36: Line 48:
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1651894,1,4 Resident Memory - OSX]
* [https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1651894,1,4 Resident Memory - OSX]


===== Testing your changes =====
To run locally use:
./mach awsy-test
To run on try for comparisons use:
hg up base_revision
./mach try -b o -p linux64 -u awsy-e10s -t none --rebuild 5
hg up new_revision
./mach try -b o -p linux64 -u awsy-e10s -t none --rebuild 5


== Meetings ==
== Meetings ==

Revision as of 19:25, 12 November 2018

Goals

Due to the drastic increase in the number of processes required to support Project Fission we must focus on reducing the per process overhead of each content process. As a baseline we are working on reducing the amount of memory used to load an about:blank page.

Metrics

Binary Section Sizes

Any writable data will increase the overhead of each content process, this is particularly problematic on Linux and OSX. This data is tracked via section_size entries in build_metrics in perfherder.

Are We Slim Yet Tests

The primary tests used by MemShrink are the Are We Slim Yet (AWSY) suite. Metrics are available in perfherder under the awsy framework.

AWSY (sb)

Our main focus for Fission is the simpler about:blank SY-e10s(ab) test. This gives a less noisy baseline metric that allows us to focus on incremental improvements. This is essentially our best case metric.

Metrics

Resident Unique is our main measurement of success. It's the total amount of memory that the content process is using that's not shared with other processes:

JavaScript is memory used by our JavaScript engine both for it's internal state and any loaded scripts. It is one of the largest contributors to memory overhead, has very little noise, and has been a focus for memory reduction:

Testing your changes

To run locally use: 

./mach awsy-test testing/awsy/awsy/test_base_memory_usage.py

To run on try for comparisons use: 

hg up base_revision
./mach try -b o -p linux64 -u awsy-base-e10s -t none --rebuild 5
hg up new_revision
./mach try -b o -p linux64 -u awsy-base-e10s -t none --rebuild 5

AWSY (sy)

The original test suite, SY-e10s(sy), is a stress test that loads 100 pages into 30 tabs 3 times and measures memory at various points and is useful for detecting regressions in startup memory usage, longer term leaks, leaked windows, etc. This is essentially our worst case metric.

Metrics

after tabs opened is one of several data points gathered, it is the most relevant to this project:

Testing your changes

To run locally use: 

./mach awsy-test

To run on try for comparisons use: 

hg up base_revision
./mach try -b o -p linux64 -u awsy-e10s -t none --rebuild 5
hg up new_revision
./mach try -b o -p linux64 -u awsy-e10s -t none --rebuild 5

Meetings

Meetings happen every Tuesday at 12:00pm Pacific time (countdown in your timezone)

  • Dial-in: Audio-only conference# 8394
    • People with Mozilla phones or softphones please dial x4000 Conf# 8394
    • US/Toll-free: +1 800 707 2533, (pin 4000) Conf# 8394
    • US/California/Mountain View: +1 650 903 0800, x4000 Conf# 8394
    • US/California/San Francisco: +1 415 762 5700, x4000 Conf# 8394
    • US/Oregon/Portland: +1 971 544 8000, x4000 Conf# 8394
    • CA/British Columbia/Vancouver: +1 778 785 1540, x4000 Conf# 8394
    • CA/Ontario/Toronto: +1 416 848 3114, x4000 Conf# 8394
    • UK/London: +44 (0)207 855 3000, x4000 Conf# 8394
    • FR/Paris: +33 1 84 88 37 37, x4000 Conf# 8394
    • Gmail Chat (requires Flash and the Google Talk plugin): paste +1 650 903 0800 into the Gmail Chat box that doesn't look like it accepts phone numbers
    • SkypeOut is free if you use the 800 number
  • Vidyo: MemShrink
  • IRC: #memshrink

Bug Tracking

Tracking: bug 1436250

Triage

We use the [overhead] whiteboard tag to flag items for triage. Additionally any bug in the bug 1436250 dependency tree is generally triaged. The triage process attempts estimate the impact a bug will have on reducing the overhead of a content process. If we think a bug will reduce per process memory usage by 30KB then update the tag with the expected win: [overhead:30K]. We try to use a reasonable guess for this value, it doesn't need to be exact.

Progress

Measurements from the beginning of each quarter.

Linux

Quarter Resident Unique JS
Q2 2018 34.3MB 8.5MB
Q3 2018 33.6MB 8.0MB
Q4 2018 20.7MB 5.3MB
Q4.5 2018 17.8MB 4.6MB

Windows

Quarter Resident Unique JS
Q2 2018 21.5MB 8.5MB
Q3 2018 20.8MB 8.0MB
Q4 2018 15.0MB 5.3MB
Q4.5 2018 15.0MB 4.8MB

OSX

Quarter Resident Unique JS
Q2 2018 32.7MB 8.5MB
Q3 2018 31.7MB 8.0MB
Q4 2018 21.4MB 5.3MB
Q4.5 2018 20.4MB 4.6MB
Retrieved from "https://wiki.allizom.org/index.php?title=Project_Fission/Memory&oldid=1203753"