Performance/MemShrink

From MozillaWiki
< Performance
Revision as of 00:33, 14 December 2011 by Amccreight (talk | contribs)
Jump to navigation Jump to search

MemShrink is a project that aims to reduce Firefox's memory consumption. There are three potential benefits:

  1. Speed. Less cache pressure, less paging, and fewer/smaller GC and CC pauses.
  2. Stability. Fewer aborts/crashes due to virtual or physical memory exhaustion. The former is mostly a problem on 32-bit Windows builds with a 2GB or 4GB virtual memory limit, the latter is mostly a problem on mobile devices that lack swap space.
  3. Reputation. Fewer people will complain about Firefox being a memory hog, and fewer people will complain that Mozilla ignores memory usage.

Reducing memory consumption directly helps with both stability and reputation. The effects on speed are usually murkier, and the effects depend greatly on the nature of any individual reduction and the machine Firefox is running on; changes that reduce Firefox's memory consumption but make it slower are not desirable.

There are two main facets to this:

  1. "Slimmer" memory usage, e.g. more space-efficient data structures.
  2. Avoiding "leaks". This loose use of the term (which is used throughout this document) includes:
  • True leaks, where memory is lost forever.
  • Lifetime issues, where memory is not reclaimed until you close the page/tab/window/process.
  • Collection heuristic issues (e.g. GC is too infrequent in certain cases).
  • Bad cache algorithms and poorly tuned caches.
  • Fragmentation.

Leaks are generally more important, as they are more likely to lead to horrible performance.

Meetings

Meetings will happen every Tuesday at 2pm Pacific time.


  • Dial-in: Audio-only conference# 95346
    • People with Mozilla phones or softphones please dial x4000 Conf# 95346
    • US/Toll-free: +1 800 707 2533, (pin 4000) Conf# 95346
    • US/California/Mountain View: +1 650 903 0800, x4000 Conf# 95346
    • US/California/San Francisco: +1 415 762 5700, x4000 Conf# 95346
    • US/Oregon/Portland: +1 971 544 8000, x4000 Conf# 95346
    • CA/British Columbia/Vancouver: +1 778 785 1540, x4000 Conf# 95346
    • CA/Ontario/Toronto: +1 416 848 3114, x4000 Conf# 95346
    • UK/London: +44 (0)207 855 3000, x4000 Conf# 95346
    • FR/Paris: +33 1 84 88 37 37, x4000 Conf# 95346
    • 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: PB&J
  • IRC: #memshrink
  • Etherpad: memshrink (copied to wiki after the meeting)

Ideally, these weekly meetings would only be needed for a medium length of time, say 1 or 2 quarters. Hopefully after that, things will have improved enough that meetings could be less frequent (bi-weekly or monthly) or not needed at all.

Minutes and Progress Reports

Bug Tracking

Bugs tracked by the MemShrink project are prioritized by adding one of "MemShrink:P1", "MemShrink:P2" or "MemShrink:P3" to the whiteboard.

Some other interesting bug lists.

There's also a tracking bug for bugs relating to profiling, tools and infrastructure. (These bugs overlap several of the above lists.)

areweslimyet.com

jmuizelaar set up AWSY, inspired by AWFY.

Why was AWFY so successful? Some key characteristics.

  • The benchmarks were easy to choose: everybody already used SS and V8, and then Mozilla released Kraken. They run quickly, too, which is nice for devs, and allows expensive tools (like Cachegrind) to be used.
  • The metrics were easy to choose. SS time, V8 time, Kraken time. They can be measured easily, precisely, and fairly repeatably. You can break the total time down into per-benchmark times, which really helps with understanding improvements and regressions. They're easy for devs to run on their own machine.
  • Understanding where the time went was fairly easy, because there are good time-oriented profilers: Shark, Cachegrind, etc.
  • There was a well-defined goal: match or beat the other browsers.

In comparison, for AWSY there is no good and/or standard benchmark suite; metrics are less clear and/or harder to measure; the memory profiling tools aren't as good; but most importantly, there's no well-defined goal w.r.t. any benchmarks.

A more trackable goal is to get the number of MemShrink P1 bugs down to zero. That will mean that all the bad leaks will have been fixed, and also the important auxiliary work (e.g. infrastructure to detect regressions) will be in place. Therefore, areweslimyet.com just points to the list of open MemShrink P1 bugs.

Retrieved from "https://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=Performance/MemShrink&oldid=378631"