HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

Firefox memory problems (part 2)

Firefox memory problems (part 2) So last night I found Firefox had eaten 1GB by the end of the day, even though I'd closed all my tabs, and I blogged about it.

I came to the conclusion Firebug is a big part of the problem due to the orphaned compartments, and laid some scorn on the people at the top of Mozilla for not allocating sufficient resources so it gets fixed. Just to be clear, Firebug does seem to be funded by Mozilla, and is essentially Firefox's equivalent of what the other browsers now have built in. Don't get me wrong, I love Firebug, and the concepts it pioneered has changed the lives of web developers, and I think Firefox was a real pioneer too – but I really think for an organisation with so many resources, and such a legacy of great engineering, something is seriously wrong with the management.

Anyway, after disabling Firebug I'd hoped I'd see the probems resolved. Unfortunately not, because my memory has been creeping up today too.

There's nothing wrong or unusual with my machine or Firefox install. The Firefox install is basically fresh, as I have only been using it for testing since installing my OS a few months ago. I'm on a very standard iMac.

So I thought I'd run some more tests today. I created a simple technique to monitor how Firefox is using memory:
  1. Open Firefox (it has to be set to not load a home page – it has to start blank)
  2. Go to "about: memory"
  3. Wait a few seconds until things settle (very important)
  4. In the Mac "Activity Monitor" tool, record what the "Real mem" value is
  5. Open a specific folder of 14 bookmarks in new tabs (using "Open all in tabs" from the bookmarks menu)
  6. Wait for them to load
  7. Close them all
  8. In the "about memory" tab we initially opened, click "Minimize memory usage". There should not no identifiable URLs showing as compartments. If there are, wait a few seconds, and try again. This is important to make sure any background downloads are finished, because Firefox won't free the RAM until they have.
  9. Record the "Real mem" value, after things have settled on there (again, very important – the OS has to be given enough time to finish and outstanding processes and to free up deallocated RAM)
  10. Go back to step 5, repeating 2 more times (ideally we'd do more tests, but I haven't got much time)

I did this process for different combinations of installed addons, with the following results:


No addons at all
160 (+45)
163 (+3)
175 (+12)

ColorZilla, Console2, Copy Urls Expert, LastPass, Live HTTP Headers
188 (+36)
194 (+6)
197 (+3)

ColorZilla, Console2, Copy Urls Expert, LastPass, Live HTTP Headers, MeasureIt, RAMBack
183 (+29)
191 (+8)
198 (+7)

ColorZilla, Console2, Copy Urls Expert, LastPass, Live HTTP Headers, MeasureIt, Page Speed, RAMBack
192 (+49)
198 (+6)
201 (+3)

ColorZilla, Console2, Copy Urls Expert, LastPass, Live HTTP Headers, MeasureIt, Page Speed, RAMBack, Selection Links, Web Developer, Xmarks
233 (+46)
240 (+7)
244 (+4)
246 (+2)
250 (+4)
(continued on further on this one to show the pattern continues)

As you can see, the first step 9 measurement has a big increment over the initial step 4 measurement. That is to be expected because Firefox will be loading up various libraries upon demand (or similar), to serve the functionality required. It is correct that Firefox doesn't free these later on, because they'll be needed again. It makes sense from a programming and performance point of view to load framework stuff on demand but to keep it.

The next measurement shows roughly 7MB, then roughly it takes 3MB for each repeat trial, all regardless of what addons you have. This makes sense because Firefox is configured with a 5MB cache so I'd expect initially things would fill up a bit but for that trend to not continue. The key thing is the 3MB, which translates to 219KB per page of leakage (1024*3/14). The data is a bit noisy, but that's to be expected, you can still see something is going on here.

If this was a proper scientific process, I'd repeat it for other browsers, take more data points, and I would look into detail on how the exact figures in "about: memory" change. But I think this is enough to show there is a real problem here. The 219KB leakage happened for pages that were initially opened and closed very quickly. Whatever the leaks are, interacting with pages likely causes it too, so real leakage will be higher - and these multiply up quickly.

View all


There have been no trackbacks yet