Notes On Reducing Firefox's Memory Consumption

Skuto writes "At yesterdays linux.conf.au Browser miniconference in Ballarat, Australia, Mozilla engineer Nicholas Nethercote gave a detailed presentation about the history of Firefox's memory consumption. The 37 slides-with-notes explain in gritty detail what caused Firefox 4's memory usage to be higher than expected, how many leaks and accidental memory use bugs were tracked down with Valgrind plugins, as well as the pitfalls of common memory allocation strategies. Current work is now focused on reducing the memory usage of popular add-ons such as AdBlock, GreaseMonkey and Firebug. Required reading for people working on large software projects, or those who missed that Firefox is now one of the most memory-efficient browsers in heavy usage."

Firefox is required anyway.

[Tsingi]

I use other browsers for development, but only Firefox to browse, it's the only browser that I feel is actively protecting my privacy.

Any other opinions on that?

Re:Give us more options

[hedwards]

250ish MB or RAM is hardly unreasonable and is significantly better than the alternatives. If you don't like the RAM use with Firefox then you sure as hell aren't going to be happy with the competition. I haven't seen a benchmark or other comparison in a long time where Firefox didn't trounce the competition by a significant margin.

TFA does raise an important point that the memory consumption problems are mostly with certain add ons. The vanilla install itself doesn't have those issues.

Pale Moon browser

[kriston]

Windows users should investigate the Pale Moon browser over at www.palemoon.org. Firefox optimized and without all the gunk.

Memory leaks are easy

[kbg]

I have never understood why memory leaks are so problematic to find. When I was programming in C long ago and had memory leaks, I simply created my own wrappers for malloc and free that stored where in the source code it was being called from, then at the end of the program I could simply check this list and it would display all the memory that had not been released and the corresponding line in the source where malloc was called.

Re:Memory leaks are easy

[BZ]

You should read the article, which actually touches on this. One issue is that a "memory leak" can include memory that does in fact get released at shutdown, especially in garbage-collected systems (not a problem in C, of course).

So you can have situations where you close a tab but its memory is kept alive for a while because an extension is referencing it. Not a leak in the C sense, but a leak in the sense the user cares about.