MemShrink meetings are go: Tuesday 1pm (Pacific time)

Exactly three months ago I wrote about a new project called MemShrink, the aim of which was to reduce Firefox’s memory usage.  Thanks to Johnny Stenback we will now have weekly MemShrink meetings in which bug reports will be discussed, triaged and assigned, and anything else relevant (see this wiki page) will be discussed.  These meetings will take place every week at Tuesday 1pm, Pacific time;  the first one will be on June 14.

This is great news!  MemShrink was never going to be more than a niche effort without weekly meetings.  To give you an idea of how important I think they are, I’ll be attending them even though it’ll be 6am Wednesday in my timezone.  So come along or dial-in.  Johnny will post dial-in instructions to the dev-platform list/newsgroup some time before the meeting.

10 replies on “MemShrink meetings are go: Tuesday 1pm (Pacific time)”

It sounds like Firefox needs a shrink!


congrats and good luck with this project 🙂

if i may…

MemShrink team here are my sugestions…

1. give me an about:memory that shows how much memory each addon is using

2. give me the possibility to kill the addons that i am not using or that are wasting to much memory

3. (this one could be more complicated) give me something like Linux kernel modules, i install all the addons i want but when i’m not using it the browser unloads them and loads it when i require that function


Wonderful news! in a few other places people had suggested one _critical_ feature and this is something that will tell users how much memory the various plugins are using – I don’t know the best place to suggest this but when my FF4 is up around 2GB of RAM used I’d love to know what is causing it – might also take a LOT of the heat off the FF devs if users knew that the draw was coming from a plugin. Just my 2c – good luck with the project!

There is an easy way to find a lot of bugs. Be aware of warnings! e.g. g++ or clang produce a tons of warnings. (Just enable all of the warning options.) Secondly, there are several very good tools out there for testing, for example, cppcheck and valgrind. I would be very happy, if Mozilla could do something similar to Debian DACA. For example, a nightly cppcheck report for every development version would be wonderful. (If the discoverd bugs will be fixed.) Valgrind is a harder tool but its memchek and callgrind tool are amazing.

Plugins: well, a plugin could cause a big problem. However, with a good garbage collector and with a memory footprint monitoring could change the world. (I think in a plugin wich can monitor the other plugins and can draw a fancy memory(time) diagrams. Just like ‘munin’ can do for linux systems.) I think if on the addons site statistics like memory consumption were published most of the addon developers do a better job. (They would have tools and motivations.))

Anyway, it’s a big step in the right direction. Good luck!

In the past I always thought that loading images in Firefox was slow. And loading a lot of images made Firefox quickly have a large memory footprint and slow down Firefox to a crawl (even without swapping).

I know Firefox caches (even closed) tabs for a while in memory. I don’t know if Firefox keeps images uncompressed in memory.

As I mentioned Firefox was at the time not very fast loading images I tested this on my Linux box and on Windows and compared against Opera, IE, Chrome with a simple html-page with a lot of img-tags and an onload events.

Maybe it is already fixed in a newer versions, I haven’t checked again.

But it might be something interresting to have someone do some tests on.

i want to be able to find out how much ram and cpu each tab uses as i often get 100% cpu usage and but don’t know which tab of my 40 or so tabs it is so i can’t report the bug.

Please focus on performance, not total memory.

RAM is cheap, for those with a lot of it to spare, Firefox should use more, however it should never use that memory slowly.

Does MemShrink mean your focus on page faults will reduce? That would be a shame as I think you were on to something there.

Just dawned on me that the quickest, easiest, and by far the largest footprint win you could get would be just *not leaving plugin-container running indefinitely*, duh.

It’s no wonder ff gets such a terrible rep for leaks (which this isn’t, but it obviously is a laughably-bad footprint issue) when it doesn’t even bother to clean up HUNDREDS OF MB from a child belonging to a tab which was closed an hour ago.

I know YOU know what a refcount is, but apparently nobody else at mozilla does. That’s just pathetic. 🙁

I’ve been keeping a casual eye on the efforts, and there’s a lot of good stuff coming out of them.

about:compartments is a great clarification tool for users who want to know “why this POS is using 800MB for only 3 tabs” and potentially a massive “PR win” because you can point at FaceBook or whoever and say “because THOSE people are monkeys, not us”.
(Of course, the fact that it just sat there being ignored for nearly 6 months only emphasises how much nobody gave a damn about ff’s rambloat, but hopefully your example will be able to change that attitude in some other devs).

Keep fighting the good fight. gl 🙂

Block countless web tracking with NoScript (select IFRAME in options to block Facebook tracking on lots of web sites as well, you can tell it to block Flash objects too but you can choose to make exceptions so for example a video on you don’t have to click it to allow it to play) & Adblock+ (w/ EasyPrivacy list) and you can speed up Firefox. I also block stuff in my hosts file, for example, search or for something like “someone who cares hosts file” to tell you what and how to do it.

Also turn off “Google updater” in your Plug-ins (not addon) if you have it because it takes a lot of memory and doesn’t do anything of value.

Chrome uses more power and is CPU hungry. Open the same amount of tabs in Chrome as in Firefox and Chrome has higher memory usage when you add up the processes in Task Manager/Activity Monitor/Unix[-like] equivalent/Haiku equivalent.

Comments are closed.