about:memory AdBlock Plus add-ons compartments DMD Firefox Garbage Collection JägerMonkey Massif Memory allocation Memory consumption MemShrink Performance SQLite Talks Valgrind

Notes on Reducing Firefox’s Memory Consumption

I gave a talk yesterday at the Browser MiniConf, held in Ballarat, Australia.  Its title was “Notes On Reducing Firefox’s Memory Consumption”.

Below are the slides and notes in a SlideShare embedding. If you find that embedding problematic (some people do) you may prefer to download the PDF version directly.

25 replies on “Notes on Reducing Firefox’s Memory Consumption”

Really? I like firefox but it take to much Memory, so I mainly use chrome and Avant browser now.Just downloaded the file. Hope the information in the file is helpful .

It won’t be much help to users, it’s mostly about internal development details.

Under what circumstances have you seen Firefox use too much memory? When did you last try it? The current versions (e.g. 9 is the current stable release) are much better than some of the older versions.

Also, did you have add-ons installed? Some add-ons have bad memory leaks, and that can really slow the whole browser down.

Chrome is just as bad as Firefox.
Or just as good if you’re a Google fanboy.

That Firebug is using a lot of memory is only an issue for developers.
I know hardly any non developers that are using Firebug.

Results vary, some people find Chrome to be terrible, some people find Firefox to be terrible. It’s weird.

As for Firebug, it has 2.8 million users and has risen to #5 on What magnifies that is that web developers are influential users — they’re the kind of people who are likely to recommend their friends and family change to a different browser. Those are the kinds of people who first started switching to Chrome and we’d like to get back to using Firefox.

Nice writeup, Nicholas. Since having add-ons is a critical feature of Firefox and memory leaks are P1 bugs, I wonder why don’t you detect those zombie compartment and other kinds of leaks on a dedicated try server, that would automatically produced a mem use report, readily available for addon devs. Or isn’t it feasible?

The hard part is that to trigger zombies in an add-on usually requires exercising that add-on’s specific functionality. And because every add-on is different, there’s no feasible way to do that automatically. That’s why adding it to the review checklist is a good idea, because a person can do it manually in just a couple of minutes.

Doing the allocation debugging iteratively helps a bit with the slowdown caused by the tools, like described here:

Sources for this tool are here:

(Debian packaging is in maemo-packaging branch. Couple of patches for 64-bit machines are in amd64 branch which hasn’t yet been merged to head.)

Terrific article! Are there any instructions anywhere for how an add-on developer like myself can use the about:memory interface to see if my add-ons create zombie compartments? Are there any best practices for tracking them down? I’ve always wondered whether my extensions have leaks, but I’ve never exactly known how to track them down (if they are indeed there).

a year ago, FF’s memory usage was about 10x what chrome was using in respect to the sites we were running, which were heavy in svg rendering and ajax calls. FF was also just as bad as IE when it came to manipulating the DOM, where we would often run out of memory on both, but not on chrome (adding and removing thousands of elements in a page via javascript).

so we have switched to chrome (these are internal sites, so we can be guaranteed that the client will have chrome). i’m told chrome’s auto-update process makes things very handy as well, and our admins prefer chrome due to the update process (i admittedly have no clue what they are talking about when it comes to installs and maintenance).

i just tested FF 9.0.1 against chrome, and it actually is running better than chrome in the memory department, which is good. but, it’s not good enough to make us switch back (running maybe 20% better in terms of memory). a tenfold difference would warrant a switch. in our instance, it was too little, too late.

but glad you are making improvements.

I’m glad Firefox is doing better, though it’s a shame we lost you as a user 🙁

It’s not a MemShrink bug because the MemShrink project focuses only on reducing memory consumption, and this is a specific responsiveness issue. Yes, I realize that memory consumption can affect responsiveness, but it’s not obvious that memory consumption is the problem in that bug. Project Snappy is a MemShrink-like project that’s targetting responsiveness, see

Also, bug reports like that one are a nightmare. You’ve got a vague, common problem that could be caused by a number of different underlying causes, and 50 different people jump on and say “I have this problem too!” and the bug report becomes useless and uncloseable. I try to prevent bugs like that from occurring — if someone reports a vague bug like “high memory usage” I do my best to make it more specific: about a particular site, configuration, whatever, and ask others who pile on to file separate bug reports.

Nice write-up!

One experience from my work with leaks on Gnumeric is that nothing
beats pointing out leaks early — preferably on the contributors machine
during his or her testing.

To that end we have a ridiculously simple mechanism: we count allocations
of a few, key data structures. ++ on allocate, — on free. print on exit, if
non-zero. As far as I know we have never screwed up the counting.
It’s always on and when it fails it’s typically obvious why. If not, we
bring out the big toys.

You probably cannot rely on exit as a checkpoint for this, but tab closure
might work: closing a tab really ought to bring say something like “hey buddy, that tab you just closed caused 3 compartments to turn zombie”
At least for nightly builds.

@M Welinder: The problem with that scheme is that you waste time freeing memory on exit instead of letting the OS do it automatically.

@njn: I liked your “clownshoes” word and have fine grained it further:

1. “physical clownshoes” – are like malloc(1024+1) returning a valid block of 1025 bytes but the allocator has ~1023 of slop.

2. “logical clownshoes” – are like a vector allocating using malloc(round2(1024+1) – MALLOC_HEADER_OVERHEAD) but the extra memory is never even used.

3. “effective clownshoes” – physical and/or logical clownshoes.

I noticed that you’ve done some work to turn physical clownshoes into logical clownshoes but I’d work to get rid of those too. In my programming language, I have a compacting GC which will alter data structures (because it deliberately has knowledge of the language instead of treating it as a general purpose GC) to make them smaller, including getting rid of logical clownshoes.

Fascinating stuff. I’ve had FF using about 8G bytes of memory on my desktop PC, but I do tend to have several hundred tabs open at a time.

I’m reading this on a netbook which has no swap partition (SSD disks = I’m reluctant to have all the writes). I also remember the IBM PC’s old 640k limit, and part of me thinks 2G RAM should be enough. But with FF, it often wasn’t, even though I had ‘only’ 50-60 tabs open, so I’ve been using Chromium.

I’m going to have to try FF again on the netbook 🙂

Please do try FF again and let me know how it goes. Different people get different results, but I’ve heard it commonly said that FF tends to handle lots of tabs better than Chrome. If you do try FF again, it’s a good idea to completely delete any old profiles you might have hanging around, they can get corrupted sometimes which screws up everything.

Unfortunately there’s currently no “import my bookmarks and history from Chrome” option in the stable release of Firefox, but I think if might be coming in FF11?

How about a ‘clean my profile’ option? It’s one thing to suggest people change to a new profile however it’s not really that simple. What if their existing profile links to Sync? How does that work? What if you want to maintain the increasingly imperative set of credentials stored in your profile? Losing passwords, bookmarks/history, preferences … any of the usual stuff stored in a profile can be a real nightmare.

Why don’t Mozilla build software that actually helps the user in that it is written to prevent profile corruption or better still, fix it?

I didn’t know you were a core Valgrind contributor! Thanks for the presentation, I learned a lot more about the memshrink effort.

FF take much RAM usage….thats not much problem but my laptop CPU get very hot and the fans is noisy cooling the system when I use FF…this can damage the motherboard…

Comments are closed.