Categories
add-ons Firefox Memory consumption MemShrink

MemShrink progress, week 61–62

It’s been a quiet fortnight for MemShrink.

The biggest news is that Kyle Huey made a change so that Firefox discards images that have been removed from the DOM.  This might sound boring, but it’s important because (among other things) it can greatly reduce the amount of memory used for photo slideshows on Facebook.  Kyle first started working on this patch nearly a year ago, and had to overcome numerous hurdles along the way.  This is a nice improvement to our foreground tab image handling, which is the #1 remaining MemShrink problem.  But there’s still lots of room to improve on that front.

The following add-ons had memory leaks fixed: 1Password, Web Developer, CoKnown Research & Webpage Clipping Toolbar, aaQQin.  The latter three were zombie compartments, a problem that Firefox 15 (due for release next week) should make impossible.  Still, it was nice of the authors to fix the problem early rather than waiting for it to be fixed for them!

Gian-Carlo Pascutto finished a huge overhaul of the SafeBrowsing implementation.  I won’t pretend to understand the changes, but it was marked as a MemShrink:P2 change and so hopefully reduced memory consumption in some notable fashion 🙂

Here are the current bug counts.

  • P1: 24 (-0/+1)
  • P2: 89 (-3/+3)
  • P3: 98 (-8/+1)
  • Unprioritized: 2 (-1/+2)

A small reduction.

7 replies on “MemShrink progress, week 61–62”

I assume the “quiet fortnight” comment means that the significant improvements shown on AWSY beginning August 15 fall under the category of something significant that you’re not aware of the root cause of. Since this also occurred with several other recent shifts, I’m wondering how difficult an automated tool to track down the commits behind them would be.

My idea would be to take a sequential list of the commits between the before/after points on the graph and perform a (binary?) search over the list building and testing them until the commits responsible for the performance delta has been identified.

The unknowns needed to determine if this would be feasible are how many commits typically occur between points graphed on AWSY and how long a typical build/test run takes.

I see a mild improvement in the past two weeks. I don’t know the cause. I also don’t stress about every up and down movement on AWSY — it’s a single benchmark, and memory consumption is a secondary metric that’s interesting primarily because of its effect on performance and stability. I view it mostly as a sanity check against big regressions.

Nicholas

I wish you’d find another way to say that memory is “interesting primarily because of its effect on performance and stability”. It is also important because of the effect it has on the performance and stability of other applications that are running on the same machine.

Having said that, this is nit-picking because what you are doing is making a real difference

The memory usage of the current Nightly version seems to be regressed. After some time, the memory usage could easily jump to >300MB, while the Aurora version is much better. I do not see such regression on areweslimyet.com, but I do feel it. Any insights?

Comments are closed.