Tuesday, November 13th, 2007

Mozilla hunting for memory

Category: Debugging, Firefox, Performance

Firefox used to be the lean mean fast browser. Well, definitely fast. People flocked to it, in part, due to its speed. These days it seems like it is falling back and people are jumping on WebKit nightly, Opera, and even IE 7 as faster alternatives.

Mozilla is a little flummoxed by the birds memory appetite, and is going on a crusade to hunt down the issues, which are even more of an issue in mobile.

Stuart Parmenter, a Moz developer, has been doing some painful hard work for us. He started out discussing the memory fragmentation issue:

I’ve been doing a lot of work trying to figure out why after loading a lot of pages much of your memory seems to disappear. I’ve tested all sorts of things — disabling extensions, plugins, images, etc. I’ve run leak tools over and over looking for things we might be leaking. Occasionally I’ll find something small we’re actually leaking but more often than not I don’t see any real leaks. This lead me to wonder where our memory went. Firefox has a lot of caches internally for performance reasons. These include things like the back/forward cache (which helps speed up loading pages when you hit back), the image cache (keeps images in memory to help load them faster), font cache, textrun cache (short lived, but used to cache computed glyph indicies and metrics and such), etc. We also introduced in Gecko 1.9 the cycle collector which hopes to avoid cycles in XPCOM objects that we might hit. We’ve also got the JS garbage collector. All of these things mean we could be holding on to a bunch of objects that could be taking up space so we want to eliminate those from the picture. I released the RAMBack extension earlier this week which clears most of these things.

So, if it is none of these things, what is going on? Why after a while do we end up using more memory than we should be if we aren’t leaking and our caches are clear? At least part of it seems to be due to memory fragmentation.

At this point he tests the browser by opening up the browser on certain sites and taking them off. He then takes a peek at the heap:

He just followed up this post with another on Windows Low Fragmentation Heap which has some surprising results.

Knowing that someone is actively working on the issue is psychologically huge, so kudos to Stuart for sharing some of his initial findings, and good luck hunting!

Posted by Dion Almaer at 7:09 am
13 Comments

++++-
4.1 rating from 30 votes

13 Comments »

Comments feed TrackBack URI

Knowing that someone is actively working on the issue is psychologically huge?
For how long is it known that FF as a big memory problem? I still use FF, but it is not because FF is such a good product but only because it is better than the others!

Comment by FF — November 13, 2007

Good to hear that someone is working on this issue. After a day of development firefox sometimes eats more than 500 MB of my RAM which is inacceptable.

Comment by Andreas Stephan — November 13, 2007

Its nice to see that this is being looked at and analyzed. I’ve recently switched to Safari on my Mac and Opera/IE7 on my PC whenever I’m not doing development simply because Firefox gets incredibly slow if you leave it open.

Comment by Andy Kant — November 13, 2007

The core product that is Gecko rarely leaks these days; indeed the build system now puts up a warning if a single leak is detected ( https://bugzilla.mozilla.org/show_bug.cgi?id=390916 ). However it’s still obviously possible for extensions to leak.

Comment by Robin — November 13, 2007

have to agree that Firefox on the Mac is super slow when you leave it open. There is a way to setup a proxy and fix the issue, but you can actually time the delays with Spinner and they are in the neighborhood of 3-5 seconds. I hope they fix that… I have also switched to Safari on Mac for most browsing (would prefer to use FF b/c of the plugins. I miss my Del.icio.us plugin on FF)

Comment by Mark Holton — November 13, 2007

I have FF loaded with add-ons, multiple tabs open, and have no problem with it eating up memory. One of the add-ons is CacheStatus which I have set to dump RAM at 20MB.

Comment by John S — November 13, 2007

Yesterday my FF reached 650 mb RAM

Comment by Simon Brüchner — November 14, 2007

I’m convinced that the memory leak problems were allowed to creep into the code because the development testing process was cut off from typical end-users. Mozilla decided that developers are geniuses too lofty to be pestered by the hoi polloi who use flickr and imageshack. Thus, it was natural that Moz slapped away reports that MySpacers were uninstalling ver 2.0 to go back to ver 1.0.
Going further, I say that Goodger should be impeached — he’s the one who reassured us that memory leaks are features!

Comment by fluxam — November 14, 2007

If you want some decent tools for analysing memory you should look at these:
VM Validator – free, memory usage viewer. Great for spotting paging
usage and fragmentation. http://www.softwareverify.com/cpp/virtual_memory/index.html

Memory Validator – commercial (VM Validator’s big brother). Lots of
analysis options.
http://www.softwareverify.com/cpp/memory/index.html

Both are Windows only and from the same people that provide the only commercial JavaScript coverage and memory tools, Software Verification.

Comment by Stephen Kellett — November 14, 2007

I’m at moment working on a website where we dynamically inserts a table with about 20-30 rows via the DOM, each assigned a onclick event. On my MacBook Pro core duo2 2.3 GHz, I experience that Ff for Mac continuously uses about 70% of my processor (out of 200%) when i ad this table!? – I might have done something wrong, but can’t find any obvious faults, so I guess the problem is that Ff find it hard to handle the onclick event attached to each table row!? (In Safari3 this web app screams by the way)

Comment by Rasmus L. Knabe — November 15, 2007

Rasmus – wouldn’t it be a better idea to have a single onclick and use event bubbling?

Comment by Robin — November 16, 2007

Robin:

I’m a beginner at Javascript, and most of the javascript in our web app is programed by a friend of mine.. but maybe your right – if this could solve our problem in Ff it would be great! (And if i wrongly have accused Ff for a fault that’s ours i apologize – just seems wierd that a simple web app can monopolize 70% of my CPU!?)

Will try and check event bubbling out – thanks! :-)

Comment by Rasmus L. Knabe — November 16, 2007

It’s really about time… I love FF but it started to be way too heavy since a few versions ago!

Comment by Web Design NY — November 17, 2007

Leave a comment

You must be logged in to post a comment.