Thursday, March 13th, 2008

Firefox 3 Memory Usage

Category: Firefox, Performance

<p>Stuart Parmenter has been blogging about his work on memory usage and various malloc() libraries and their tradeoffs.

In his latest, he talks about the memory usage in Firefox 3 today and the work that he has done:

  • Reduced Memory fragmentation: One of the things we did to help was to minimize the number of total allocations we did, to avoid unnecessarily churning memory. We’ve managed to reduce allocations in almost all areas of our code base.
  • Fixed cycles with the Cycle collector: For Gecko 1.9, we’ve implemented an automated cycle collector that can recognize cycles in the in-memory object graph and break them automatically.
  • Tuned our caches: In many cases we’ve added expiration policies to our caches which give performance benefits in the most important cases, but don’t eat up memory forever. We now expire cached documents in the back/forward cache after 30 minutes since you likely won’t be going back to them anytime soon. We have timer based font caches as well as caches of computed text metrics that are very short lived.
  • Adjusted how we store image data: In Firefox 3, thanks to some work by Federico Mena-Quintero (of GNOME fame), we now throw away the uncompressed data after it hasn’t been used for a short while. Another fantastic change from Alfred Kayser changed the way we store animated GIFs so that they take up a lot less memory. We now store the animated frames as 8bit data along with a palette rather than storing them as 32 bits per pixel.

What about the tests?

For the results below we loaded 29 different web pages through 30 windows over 11 cycles (319 total page loads), always opening a new window for each page load (closing the oldest window alive once we hit 30 windows). At the end we close all the windows but one and let the browser sit for a few minutes so see if they will reclaim memory, clear short-term caches, etc. There is a 3 second delay between page loads to try and get all the browsers to take the same amount of time.

Great work guys, and thanks for talking to us about how you are doing this work!

Related Content:

7 Comments »

Comments feed TrackBack URI

well, for me the latest firefox beta is indeed going where no browser has gone before – 1.2GIGS of ram taken with around 25 tabs! sheesh!
It only happens from time to time, but when it does it’s really annoying.

Comment by clarity — March 13, 2008

That’s not exactly true – I had FF2 up to 1.2 gigs last week with 10 tabs :-)

Comment by sos — March 13, 2008

One thing which isn’t answered by this tests is a long running applications which creates more and more JS instances over time. By long running I mean something from 15 minutes to 4 hours. Would be interesting what something like Zimbra or GMX costs when executed for such a time. During this time you have maybe read about 100 mails, opened some folders, open and closed a lot of dialogs, had at least 1000 xmlhttp requests. Would be highly interested to get some info about such large scale applications.

Comment by wpbasti — March 13, 2008

The memory usage characteristics this article talks about unfortunately miss the real problem with current browsers. Both Firefox 2 and 3 use a stable amount of memory in this example. And for most people it’s not the point whether that’s 200 or 300 MB – or even 500 MB – as long as it’s stable.

The real problem is that any current browser – including those mentioned in this article – have big trouble with not letting the memory usage increase to extreme values like 1 – 2 GB. Especially js-intensive web applications tend to get slower and slower over time and consume more memory every hour.

This must be fixed to make JS intensive web applications be serious competition to offline apps or Flash apps.

Comment by bslagter — March 14, 2008

bslagter: that’s funny, we have complaints about Flash using too much memory reported to bugzilla.mozilla.org. The fact is that no runtime I know of puts a priori limits on allocation. It’s too easy to break legitimate apps that way.

If you have a runaway JS app, or even an intentional denial of service attack, that’s bad and we should try to keep such things from grinding your machine into the ground. SpiderMonkey and other parts of Firefox do have generous quotas and similary “sanity” enforcement checks, but there are lots of places to patch.

This is not the right design focus, though, at least not now. Firefox 2 and older were leak-prone in ways that the XPCOM cycle collector fixes in Firefox 3. malloc fragmentation was also a problem, fixed now as best we know how. There’s no utopia, but Firefox 3 has overcome what I think are the first-order problems in past releases (and in some other current and beta browsers, it turns out).

There’s more work to do for sure, and browser competition is heating up, which should mean things get better, faster. Good news for web developers.

/be

Comment by BrendanEich — March 14, 2008

Another higher-order bit we’re looking at: fire-walling plugins and even whole tabs or windows using OS processes. Nothing like the hardware MMU to keep misbehaving code at bay. Konqueror always ran plugins out of process IIRC, and other browsers are going here too. It’s the revenge of Plan 9, which failed to succeed Unix as an OS.

/be

Comment by BrendanEich — March 14, 2008

I’ve always used tons of tabs in browsers – ever since opera in 2002 when I started using that. Firefox 3 uses a lot less memory than firefox 2 on my computers. In fact it seems to load a lot of things faster. I think what I like best is that after I close some tabs, the memory is actually released.

Comment by MattEllsworth — April 3, 2008

Leave a comment

You must be logged in to post a comment.