Notes On Reducing Firefox's Memory Consumption 297
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."
Re:misslabeled linke (Score:5, Informative)
The final link actually shows Firefox is one of the most memory inefficient browsers in heavy usage.
That depends on how you look at it. With one tab open it is comparatively poor, but with 40 tabs open it's very good.
I don't particularly think FFX has even close to the best performance, but those metrics are good. What's more important, good management with a low footprint or a high one? I have to disagree with you there.
Re:Firefox's problem (Score:4, Informative)
It depends which ones you're talking about. Some of them are already in their own separate process and you can kill those processes without having too much trouble. The bigger problem right now is all the freezing that goes on. I'm not sure what the problem is, but it gets a lot worse when I also have thunderbird open.
Re:Firefox is required anyway. (Score:4, Informative)
Agreed - and the power consumption is much lower than Chrome's (the only viable alternative, IMO) too.
But how do I speed it up? Chrome is MUCH faster on my machine, and I'm using a Firefox profile that's barely a year old, without many add-ons installed (NoScript and ABP go without saying... ImageZoom, NoSquint... that's pretty much it). And Firefox keeps thrashing my disk (No, I'm not swapping it out for an SSD - I only have one hard drive slot in my laptop, and it's filled with a big-ass mechanical hard drive)...
Re:Firefox's problem (Score:5, Informative)
It doesn't matter how much better Firefox is on its own at memory management, in practice many people using Firefox are using it because of the plugins (otherwise they'd be using some other browser), and the plugin developers may not be so good at memory management.
Actually, the presentation addressed that. They're going to add a notice to known bad add-ons at the Mozilla add-on page (social engineering), and also add a basic leak test to things done by the reviewers.
Re:Give us more options (Score:5, Informative)
I want firefox to use up as much of it as it can to improve my browsing experience
RTFA. When FireFox has an off-by-one error in its JavaScript string concatenation code that causes it to allocate twice as much memory as it needs for JavaScript strings, it's not using memory to improve your browsing experience, it's just using memory. When FireFox is storing decompressed images in memory that never actually make it to the screen, it's not using memory to improve your browsing experience, it's just using memory.
Most of the techniques in TFA were of general interest to anyone working on a large project, not just to FireFox.
Re:Slop analysis doesn't add up (Score:4, Informative)
See page 27 of the PDF. He explains that the allocator, jemalloc, rounds up some allocation requests to easier to handle size. He calls this wastage "slop". Then look at the final point on that page - in order to reduce slop, always allocate a power of two sized block, as those never have slop.
So in order to stop the allocator wasting memory by using up more memory than requested, we're supposed to ask for more memory than we need?
What's to stop us from changing a 1025-byte allocation to 1024 bytes, rather than 2048 bytes, as you assume? There's no reason we need round up, and indeed we usually don't.
But note that even when we do round up, it's still an improvement: The slop is rarely usable memory -- you can't use it without first calling malloc_usable_size to realize that you have any slop. But if we round 1025 up to 2048 bytes, now we have almost double the amount of memory to play with. We pay 2048 bytes either way, but when we round up, we get to use all the memory we allocated.
Re:Give us more options (Score:4, Informative)
Listen up, young'un - I remember when we bought a 10MB hard disk for our lab's HP1000 mini-computer back in the early 1980s. That thing was the size of a dishwasher.