about:memory add-ons Firefox Memory consumption MemShrink

MemShrink progress, week 38

After last week’s action, this week was quieter for MemShrink.


I mentioned last week the plan to test the top 100 add-ons for memory leaks.  Unfortunately we learned this week that the list I gathered is the top 100 installed add-ons, not the top 100 enabled add-ons.  It’s quite possible that a lot of installed “third-party” add-ons (those installed by a program outside of Firefox, such as anti-virus programs) are disabled, in which case this top 100 list won’t reflect actual usage.

As a result, the top 100 testing is on hold until we can resolve this issue.  Telemetry data may help, though that data might exhibit opt-in biases.  I’m also going to investigate the possibility of changing the daily ping to distinguish between enabled and disabled add-ons, which would give us fully representative data.

Landed patches

I merged the “dom+style” and “layout” trees in about:memory.  This is a step towards per-tab memory reporting.  It also probably breaks about:nosy 🙁

I also converted the DOM memory reporters to the new style, added measurement of URIs and links, and added measurement of the FramePropertyTable.  These changes reduced about:memory’s “heap-unclassified” by several MBs in common cases.

Bill McCloskey changed the GC marker stack so it shrinks periodically.  Previously it could grow from 256KB to over 2MB and would never be shrunk once that happened.

Bug counts

This week’s bug counts:

  • P1: 29 (-0/+1)
  • P2: 131 (-4/+6)
  • P3: 87 (-3/+7)
  • Unprioritized: 1 (-2/+1)

5 replies on “MemShrink progress, week 38”

Interesting. I hadn’t seen those graphs. I don’t know, I’ll try to find out. Thanks!

I think you should do either , Top 200 installed, which should pretty much covers enough general usage. Or Top 100 from installed and Telemetry combined. Personally i would simply go Top 100 installed and avoid all the general public confusion.

Doing so should properly bring enough public attention so other non Top 100 add on author would do something as well.

I would say the #1 reason why users disable add-ons are due to their bad implementation.

I have disabled several that has useful features but since they simply are terribly on memory or makes the UX sluggish it kills their overall usefulness.

The #1 reason I disable Add-Ons is Firefox’s inability to handle a significant number of Add-Ons. Or at least that’s what Firefox developers have told me is the case: more than half a dozen Add-Ons are abnormal. Funny that nobody sees fit to mention this limitation when pimping Firefox. Somehow the marketing people are happy to pimp Firefox’s Add-Ons as a strength, but never mention that there’s such a concept as ‘too many’ Add-Ons.

Alas my summation is merely a different way of agreeing with you Thomas – agreeing that Add-Ons are a performance problem, just not agreeing where the blame lies. Thankfully Mozilla is moving away from both our baseless summations to a quantitative approach of measuring performance and then pointing the finger. This is the same approach finally taken by the MemShrink effort in general in response to the frequent questioning of Mozilla’s memory management and until Mozilla can reliably differentiate between Add-On and Firefox regarding the cause of performance degradation, I don’t think there’s much point just blaming Add-On developers alone.

Comments are closed.