"While Firefox 2 used less memory than it's predecessor, Firefox 1.5, we intentionally restricted the number of changes to the Gecko platform (Gecko 1.8.1 was only slightly different than Gecko 1.8) on which Firefox was built. However, while the majority of people were working on Firefox 2/Gecko 1.8.1, others of us were already ripping into the platform that Firefox 3 was to be built on: Gecko 1.9. We've made more significant changes to the platform than I can count, including many to reduce our memory footprint. The result has been dramatic."
To read all comments associated with this story, please click here.
Member since:2006-01-02
CPU usage is cheap in terms of user perception (unless they're doing one of the rare sustained CPU operations, like mathematical caluclations or encoding/decoding). Excessive memory usage is far more expensive (since it often results in hitting the disk for things, which is far more noticeable than CPU spikes).
Member since:2005-07-24
Hear! Hear!
I run about 70 concurrent Gnome users on a dual Xeon 3.2GHz box. Not really much processing power by today's standards. And yet I rarely feel constrained on processor. I do, however, feel constrained on ram. I really need a minimum of about 64-96MB of physical RAM per user. Running the latest Fedora x86_64, it really takes about 128MB before I feel I have some breathing room. So I don't take kindly to the cavalier attitude Firefox devs have traditionally taken with regards to trading memory for processor. Especially, when the cost is unpredictable. For example, caching prerendered pages. We generate some pretty large reports through our browser based report generator, and I do not particularly care to have FF caching the last 8 runs.
And don't even get me started talking about the way FF just looks at the physical ram of the machine it is running on and sets its values based upon that... without ever considering just how many dozens of copies of FF might be running.
Member since:
2005-11-02
It seems to me that this aggressive freeing of memory would eat the CPU, and this on a browser that can already peak my CPU usage when rendering pages. Reclaiming memory over time for Firefox is good (a must!) but I do hope that they allow the policy to be tuneable in about:config so I can have some control over how aggressively it behaves.
I don't imagine, and it does not appear from the writeup, that they tested *my* average usage patterns, namely 100+ tabs left open for months at a time... or until the kernel kills Firefox for using too much memory (thank goodness for Session Manager)! Still, leak fixes are good and any improvement in handling retention of cached information is worthwhile, even if it doesn't help me much.