Slashdot Mirror
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.'."
A quick read through the article (sacrilege, I know) claimed a small amount of jerkiness on uncompressing images. Does anyone have any idea how this would affect various hardware? For instance I have a 333MHz Pentium with ~144MB of mem that I expect (WAG) would get extremely "jerky" using this.
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
At first, I thought so, but I just looked at my memory usage and Firefox is the top hog, beating the next two with more combined memory use. I don't mind a program taking 50MB, but it's at 116MB right now.
Firefox (on Windows) can and will suck up an infinite amount of memory. This is because under some circumstances (Well, always, at least for me and many other users) it does NOT remove the uncompressed images from memory when a tab is closed.
If I am opening and closing a lot of image-heavy tabs, after a while, my firefox instance is sucking up 800MB of system memory, and the ONLY way to free it is to restart firefox.
I don't care about firefox's memory usage with compressed versus uncompressed. If I'll get more speed with 90MB of uncompressed images, go for it. What I do have a problem with is how it doesn't bother to remove raw images that are no longer needed. Essentially, it is a really bad memory leak that they haven't fixed for ages.
As for reducing actual memory usage, a hybrid solution is best. At the very least all images on other tabs should remain compressed, and then decompressed when switching to that tab, going back to the compressed images from the old tab (Disk cache them, or keep both compressed and uncompressed in memory).
In addition, you can probably do smart-cacheing on images on the current tab. As the article author mentioned, keep uncompressed copies of only images near the current viewport. Another solution might be to store everything as compressed, even in the current tab, and modify the rendering engine so that images are drawn asynchronously. A 100ms delay while scrolling will cause noticeable hitching, but if you draw the rest of that page and throw in the image 100ms later, the user will have a much smoother experience. They can keep scrolling while the image is loaded in.
Konqueror - includes all of KDE (ugh)
Konqueror embedded - lacks maintenance
These are are both false statements.
For one, you don't need "all of KDE" to build and run Konqeuror. All you need is the kdecore libraries, all of which put together have a much smaller footprint both in memory and diskspace than Firefox. If you don't beleive me, 'apt-get install konqueror' in Debian or any other distro that segments up KDE packages.
For the second, Konqeuror embedded is built from the *exact same* cvs tree as Konqueror. Any commits to the rendering engine go to both browsers. So it does not 'lack maitenence', it is very actively developed, just like Konqueror.
Sigh. You have a very poor understanding of memory usage patterns.
Applications will seldom free memory back to the system, even though it has been freed within the program's memory manager (malloc etc). Most Unix systems give applications a single contiguous chunk of virtual memory that typically only grows rather than shrinks (due to memory fragmentation). That is a terriblly ineffective way to diagnose a memory leak.
AC