Lower Firefox's Ram Usage With This Simple Hack

tech.cybernetnews.com — This Firefox 'hack' brings the ram usage to less than 10MB whenever you minimize Firefox. IE7 and Opera both have this implemented by default and so should Firefox. This is a great way to help with the memory leaks. Apr 9, 2006 View in Crawl 4

Save
Bury

198 Comments

mrtea Apr 9, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

Digg Effect

nogoodnamesleft Apr 10, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

It's too difficult to explain here; you neat a vet to check it out properly, and they're pretty aggressive when there's a female nearby, so I wouldn't risk it.

ethanl Apr 10, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

You people need to learn what a memory leak is. <a class="user" href="http://en.wikipedia.org/wiki/Memory_leak">http://en.wikipedia.org/wiki/Memory_leak</a>

Closed Account Apr 10, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

Yes, because this option doesn't actually cause Firefox to use less memory, it simply moves the memory out of RAM increasing the likelihood that Firefox is swapped to disk, thereby reducing Firefox performance. That's why the Firefox default options are what they are.

smozoma Apr 10, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

@shinynewIt's an old habit. I have another button on my mouse set to 'show desktop,' too. And another to 'paste.'I just CTRL+Click to open a link in a new tab -- my hand is going to be on the keyboard, anyway, so it doesn't really bug me.

killerah Apr 10, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

Very cool tweak! Brought mine down to around 20 mb. Very useful, and certianly worth a digg.

zarlwilliam Apr 11, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

heh... something else opera had first... yet ppl flip over this...GO OPERA!!!!!!!!!!!!!

robertbradbury May 3, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

The problem for many people is *NOT* a "memory leak". It is a heap memory fragmentation problem. The following statements apply to Linux systems though I suspect they may be a consideration under Windows as well. Firefox is built on top of C++ and C, those use the GNU "libc" ANSI C standard malloc() and free() to allocate memory. Those in turn use the sbrk() and brk() system calls to request memory allocation from Linux (presumably some different system calls under Windows though they probably do the same thing). The only way to reduce your maximum virtual memory size is to free up a significant amount of previously allocated memory at the end of the heap and call brk() to lower your maximum heap address. The free() call *will* do this but *only* if there is a contiguous segment of memory at the end of the heap whose pages are no longer required. If that doesn't happen (because the last allocated memory in the heap is dedicated to a history entry, a bookmark, a TCP/IP buffer, a Javascript that is running, etc.) then the last heap address will never reduced and your VM usage will never decrease. This is why closing tabs or windows does *not* generally reduce your VM usage.The problem occurs when you have kept Firefox running for a long time (days in my case) and have visited lots of windows, run lots of scripts (Gmail, Wizz, Adblock, etc.), made lots of bookmarks, have lots of new history entries, etc. and your heap becomes highly fragmented -- malloc and free have to keep a list of all of the allocated and available chunks in the heap. When this happens anytime you allocate memory (or have scripts that require the garbage collector to run) there is a high probability that you may have to scan through the *entire* heap looking for available or potentially available memory. That will require significant paging of the heap to discover the fact that there may be no free memory of sufficient size and a request for more memory needs to be made to the O.S.This is a complex problem involving interactions between Firefox, the C library and the Linux VM paging algorithms. It can be solved at any of those levels. The Firefox development team should be slapped on the hands for not anticipating the problem and having the distributed browser configuration (or the install procedures) work well on machines w/o large amounts of physical memory. I was previously unaware of the "browser.cache.memory.capacity" flag and I suspect this is a good partial solution because if it does what I think it should do it will limit the size of the heap and force the browser to do its own paging rather than rely on the operating system.I believe that one Firefox/Mozilla developer has pointed out that this problem could be solved if the architecture of the system used mmap() instead of sbrk()/brk() to handle the interface between program memory and the O.S. One could create lots of virtual memory pools (one for history records, one for bookmarks, one for images, one for java scripts, etc.) which can be optimally managed depending upon the requirements for each specific pool. However I do not think that Firefox does that, perhaps in part for portability reasons (I do not believe that Windows has mmap() though it may have some equivalent function). Because malloc() and free() are the ANSI standard memory management primitives for C those are what is used and you are stuck with the consequences of how "libc" handles the program memory heap.

scrap104 May 10, 2006

0 diggs
-0 / +0

Show Buried Comment
Report

Digg
Bury

It was nice at first but I realize it was a pain. So with the RAM usage at 300 MB, I minimize it and the 300 or so gets shoved into the pagefile. I tend to minimize and restore a lot in windows and when I restore the browser window it takes a while to read that 300 MB worth of data in the pagefile (Virtual memory is a lot slower than actual memory). So I went back to the config file and deleted that tweak. Memory problems are not an issue as I open and close firefox often enough.