Firefox from my brief research simply seems to be doing C/C++ allocs & frees of the memory meaning that it is relying on glibc to handle the heap.  I think the problem is that they just seem to be grabbing more over time without paying attention to how they manage it (so you've got history table entries, bookmarks, stored scripts, gmail records (or any other "dynamic" web information) all interleaved in the heap.  So even if you free up all of the big image allocations in the heap the glibc routines still aren't going to give that space back to the 
O.S. (in Unix/Linux you have to issue a brk() call to decrease the last physical data address of the process).  The library has code in it to do that (I checked) but I doubt it is ever called because you never completely "free" the space at the high end of the heap.  So the heap gets paged which means over time performance goes through the floor as more paging has to be done to scan the heap every time you allocate or deallocate from the heap or run a garbage collection on it.
<br><br>One time after I'd run Firefox up to about 250-300MB of resident working set (probably 150+ tabs) I told it to simply "Quit" -- it did exit cleanly after *25* minutes on a machine that was doing nothing else of significance.  I watched the performance on vmstat over that period and it was almost all swap-ins of unchanged heap pages during that time as it attempted to merge all of the pieces of heap memory being freed into one large chunk before exiting.  It used virtually no CPU during this period -- it was all page faults and waiting for the pages to be swapped in.  Its a combination of poor memory management in Firefox with poor VM management in Linux.  (One needs a VM system which is intelligent enough to recognize heap thrashing and try to manage it reasonably -- which isn't trivial.)
<br><br>I could be wrong but I think Firefox is only single threaded in the communications area, not in the page format & display area.  You shouldn't *have* "processor-intensive tabs" -- thats an indication of "foreign" code being run on your machine and I would suggest people are taking very large risks if they allow sites to do that on a general basis (which is why I generally block Javascript).
<br><br>Robert<br><br><div><span class="gmail_quote">On 5/1/06, <b class="gmail_sendername">Alfio Puglisi</b> <<a href="mailto:alfio.puglisi@gmail.com">alfio.puglisi@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 5/1/06, Samantha Atkins <<a href="mailto:sjatkins@mac.com">sjatkins@mac.com</a>> wrote:<br>><br>> Ah.  Does Firefox have its on memory management internally or does it<br>> just depend on raw request to the platform alloc routines that it
<br>> then chains together.  From the description i would guess the<br>> latter.<br><br>The latter, and AFAIK it doesn't free the memory used by the images in<br>a tab when you close it, so the memory usage grows and grows. It's
<br>also single-threaded, and a processor-intensive tab can effectively<br>hang the others for quite a while.<br><br>Alfio<br><br>_______________________________________________<br>extropy-chat mailing list<br><a href="mailto:extropy-chat@lists.extropy.org">
extropy-chat@lists.extropy.org</a><br><a href="http://lists.extropy.org/mailman/listinfo.cgi/extropy-chat">http://lists.extropy.org/mailman/listinfo.cgi/extropy-chat</a><br></blockquote></div><br>