I noticed interesting behavior while observing the effect of a memory cache tweak on Firefox.
First, the tweak. Firefox caches data on disk, but it also caches data in memory. The memory cache has a leak; it doesn’t deallocate in certain situations where it should. (This is a Gecko problem, and has been fixed, but not yet integrated into the Firefox release.) Over a period of time, Firefox will increase its memory allocation to accomodate this cache, thus starving other applications of memory. However, you can set the cache’s maximum size.
In about:config
, the setting browser.cache.memory.enable
is set to true
. This is a good thing. You’ll want to add browser.cache.memory.capacity
, an integer, with a value in kilobytes, such as 16000 (or approximately 16MB). To do this, right click, and select new, then integer. Name the new preference, click OK, then enter the value, click OK, and restart Firefox.
Now the interesting thing that I observed was that on minimizing an application, it deallocates memory in the working set that it is using for window management. This can be a lot of RAM. In one case Firefox dropped its working set size from 75MB to 800K. In another, Ouchlook dropped from 45MB to 2MB. The Java runtime for Q went from 20MB to 2MB, then increased to 9MB, and again to 15MB. Note that this does not deallocate all committed pages, so while they’ll remain in memory since they’re not in the working set they will be in the virtual memory pagefile.
Using the “show desktop” icon on the taskbar appears to not deallocate pages from the working set in the same way that the minimize feature does, which is puzzling. However, by minimizing the applications which you do not use, rather than switching between them, you can slightly improve the responsiveness of your system. I say slightly because of the page faults and disk I/O associated with McAfee’s scanning the pages as they are allocated or moved from the pagefile into the working set. You’ll need to experiment somewhat to see how it works for you. The trick is to keep the committed bytes in use as low as possible, preferably less than the amount of real RAM you have in your system. To see how you’re faring, on the performance tab in Task Manager (taskmgr.exe
), there are four blocks of statistics in the lower half of the window, compare the total physical memory with the total commit charge.
Of course, there’s no substitute for spending the 150 bucks and getting another 256MB of RAM.
Wow! This is amazing. I was looking for info about the memory leak in Firefox and found your blog. I’ve worked with PCs for the last 10 years and have never noticed or read that this was the case with memory allocation under windows.
There’s a leak in Firefox at the moment, which doesn’t seem to pay any attention to that about:config tweak you’ve written about. There is another workaround, however, covered at http://kb.mozillazine.org/Memory_Leak
Hopefully this bug will be resolved with the Firefox Deer Park (v1.5) release
Thanks, Mr. B.
With regard to that leak noted at MozillaZine, I’ve found that closing the tab with the annoying Flash advertisement will stop the leak. The memory won’t be freed, but the hole will be plugged.