Reducing Firefox's Memory Use

An anonymous reader writes "Many people have complained about Firefox's memory use. Federico Mena-Quintero has a proposal for reducing the amount of memory used to store images, which, in his proof of concept code, 'reduced the cumulative memory usage... by a factor of 5.5.'."

Comments

Easier solution

[plover]

Buy more memory. It seems to be the rest of the industry's answer to resource hogging software. Look at all the bloatware out there: XML, JVMs, .NET, etc. The rest of the world is building for 1GB boxes, so who cares how efficient their code is anymore?

Coming from me, this is sarcasm, but it's a depressingly prevalent real attitude in the industry.

Re:Easier solution

[GigsVT]

With CPU development practically stagnating, but RAM and HD storage still growing fast

What?

I could believe HD, but RAM sizes have not kept up at all. You might have gotten a system with 128 megs with a 20 gig hard disk with a CPU running 800 mhz a few years ago. These days you get a system generally with something like 512 megs and 200 gigs storage running 3Ghz. Also RAM prices have not dropped all that much. 512megs of DDR2 is over $200.

Yes, CPU speeds have stagnated in the last year or so, only growing by 10-20%, but RAM hasn't advanced all that much in the size department.

Re:Easier solution

[jlarocco]

Good idea. I don't use Firefox, but that approach will ensure that next time I think about switching browsers, I'll have one less option to consider.

Don't try to play Operating System

[Clueless Moron]

While it looks like a nifty idea at first glance, this kind of memory optimization is ultimately pointless when you have a nifty demand-paged vmem kernel like Linux.

Consider: since my box has 1G of memory, I do want the X server to hang on the all those pixmaps, because that makes firefax run fast. The hack would make it waste CPU time re-uncompressing images, whether it's needed or not.

With the way Firefox works now, if memory does start to run short, well, that's when the kernel will start paging things out based on its clever working set algorithms. If a given pixmap area in the X server hasn't been accessed in quite a while, it'll get swapped out to disk and the memory reclaimed. If the pixmap is accessed later, it'll automatically page back in.

I don't know about your box, but mine (Athlon XP2000+) can decompress JPEGs at a rate of around only 3MB per second. My disk drives, OTOH, are a hell of a lot faster than that.

In other words, letting the OS do its job by tossing the images onto swap when necessary strikes me as a much better strategy than constantly sucking up CPU decompressing every image every time it's used just in case the memory might be needed.

People worry too much about VMEM, IMHO. If I write a program that allocates 1G of memory, but then spins around using only 10k for the next hour, it'll have basically zero impact on the OS. Only ~10k if real RAM is actually getting used.

Re:Interesting, but doesnt solve the biggest probl

[Skapare]

I've switched to opening links in new windows a lot now. In part this is because I want to group a set of tabs together. And it's easier to just close the whole mess by closing that whole window (generally all on one site or about one topic). But it seems FF is not free-ing up memory in these cases, either.

I don't see why a tab or a new window should be different internally, though. It should only be a matter of associating the state of a loaded page with a given display context. The real issue, though, is the memory management issue. Apparently something fundamentally wrong in the browser architecture is preventing that. I highly suspect it is due to over-abstraction and/or the inability of some tools they are using to properly destruct objects that are no longer needed. It does seem that large complex software projects such as this do tend to suffer a lot of complexity issues that result in basic things like free-ing memory becoming impossible to do. I don't encounter these problems in my programs, but then, I don't do anything nearly as large as Firefox, nor do I use a team of developers, nor do I use all these abstract tools by ignoring their internal operation implementations. I'll be curious as to the actual, real cause.

recompress

[TheSHAD0W]

This is a pretty neat idea, but JPEG compression tends to be rather CPU-intensive for various reasons. I'd recommend either recompressing to a more reasonable format - LZW, for instance - or perhaps going to an intermediate compression also based on JPEG but requiring less CPU to deal with. For instance, decompressing to 32- or 64-bit fixed-length tuplets rather than the LZ or numerical compression used in the files.

Re:Its all about cost

[An Onerous Coward]

In this case, though, the number of customers is on the order of a hundred million people.

Care to do the math again? :)

It's an important point, though. Sometimes programmer time isn't used terribly efficiently.

Re:It's the GDI objects

[Anonymous Coward]

Very true. On windows '95. Problems with system resources like this haven't been there since '98.

The GDI problems in Win9x were never fixed outright, just reduced. And the problems in Windows 2000 and XP are completely different, since they derive from NT.

http://support.microsoft.com/default.aspx?kbid=126 962

I've had older versions of ZoneAlarm hit this limit:
http://support.microsoft.com/default.aspx?kbid=326 591