Categories
add-ons Firefox Memory consumption MemShrink

MemShrink progress, week 43–44

As promised last time, this MemShrink report covers two weeks’ worth of activity.

Melbourne MemShrink Meet-up

This week Kyle Huey, Justin Lebar, Andrew McCreight, Jet Villegas flew to Melbourne to bunker down with me for a MemShrink work week.  This is great for two reasons.  First, it gives all of us an excuse/opportunity to ignore the usual myriad of attention-grabbing tasks and focus solely on MemShrink stuff for a week.  (For example, Jet is the manager of the layout team but he’s managed to do a couple of days of coding!)  Second, it lets us collaborate and pick each others’ brains much more easily and efficiently than normally.

Badd-ons

The following add-ons had zombie compartments fixed.

I’ve said before that add-on leaks are the #1 cause of high memory consumption in Firefox.  Numerous add-ons have had leaks fixed, but this is a slow process.  However, Kyle has been making good progress this week on a patch that has the potential to mitigate the majority of add-on leaks that cause zombie compartments.  It currently passes all tests on try server and is undergoing review.  Watch this space!

Version 1.6 of the Add-on SDK was released, which fixed all remaining known leaks.  Except that a new leak was found shortly before release!  This was found too late to be fixed before the deadline for 1.6, but fortunately, it was quickly fixed in version 1.6.1.  The Add-on SDK developers (especially Alexandre Poirot) have fixed a ton of leaks in the past few months, so it’s great to see this milestone reached.

Miscellaneous

Olli Pettay fixed a leak relating to event listeners.

Henrik Skupin released version 0.3 of the MemChaser add-on.  It features improvements to the UI and the logging.

Jonathan Kew optimized the representation of font character maps.  Depending on the platform, this can save around 1MB of memory, or more if you have lots of fonts installed.

Jared Wein landed an option for making plugin content click-to-play.  This isn’t marked as a MemShrink bug but if a user can ignore such content, it has the potential to reduce memory consumption significantly in some cases.

Bug counts

Here are the current bug counts.

  • P1: 22 (-1/+2)
  • P2: 84 (-56/+3)
  • P3: 100 (-8/+18)
  • Unprioritized: 0 (-1/+0)

Lots of movement there.  This is because we’ve been going through the P2 bugs and closed a lot of them because they were dups, or lacked enough information to do anything useful, or we decided they were no longer worthwhile.  We also downgraded quite a few P2 bugs to P3.  As a result, the P2 list is much more interesting than it was.  And we’re only partway through it!

A new meeting schedule

I mentioned last time that I would be writing these reports every two weeks from now on, instead of weekly.  Similarly, we’ve decided to reduce the frequency of MemShrink meetings to once every two weeks.  The next meeting will be on May 1st.

This change does not reflect a reduction in the amount of work being done on MemShrink bugs.  Rather, it reflects a reduction in the number of new MemShrink bugs being filed.  At the past few meetings we’ve had only a handful of new bugs each time and triage has only taken a few minutes.  (In comparison, in the early days of MemShrink, several times we didn’t get through all the new bugs in an hour.)

This leaves us lots of time for talking about other things;  in fact, more time than we’ve needed.  And time spent in meetings is time not spent fixing problems, so this feels like the right thing to do.

13 replies on “MemShrink progress, week 43–44”

The new tab page has had several leaks. If they’re not fixed by the time the current development cycle finishes, I will be pushing for it to be disabled until the leaks are fixed.

By Post Author

This may be a dumb question, but does the font character map optimization also reduce memory used on pages that load a lot of different web fonts as well?

Thanks!

The character map optimization may slightly reduce the memory usage of web fonts (if there are multiple web fonts that support exactly the same set of Unicode characters), but it won’t make a major difference – the character coverage maps are quite small, relative to the overall amount of font data. It’s unlikely a site would use @font-face to serve lots of large CJK (Asian) fonts, which are the fonts where larger savings can be made, so this applies primarily to fonts already installed in the OS.

(Note that even if you never visit specifically Asian-language pages, a few such fonts are likely to be used, because of sites like Wikipedia or Facebook that have links to other-language versions, displayed in the appropriate language.)

Hi Nick,
I had a question – is it possible to perhaps have areweslimyet.com but with the top 100 addons added to the test builds?

So we can see the combined improvements both from the addon authors and from Firefox itself, in single graph?

I feel this would represent much more of a real working case graph.

My concern with this is that 100 addon’s represents something far outside a ‘normal’ use case, limiting the value of the statistics and could provide competitors a very ugly number to use as an “official” Mozilla stat for attack marketing.

Comment form bug. I’m not sure if this is the correct place to report it, but it’s bitten me at least twice.

If your first captcha fails, the reply is placed at the end of the post instead of being threaded. The only indicator of this in the UI is that the “cancel reply” text adjacent to the “Leave A Reply” text goes away.

Comments are closed.