More on Firefox and some on memory leaks
I’ve seen this article in the past, but it came up in my Google reader list for some reason, so I’ll blog about it.
One of the main problems people have with using Firefox is that its such a memory hog – it eats up a lot of memory and I’ve seen instances where after running for a few days it can consume more then 1 Gigabyte of memory and as a result becomes incredibly slow as the operating system has to keep swapping browser parts in and out of virtual memory just to change tabs. This of course slows down other applications. Mozilla developers, on the other hand, claim to keep a really tight ship and to test for and fix memory leaks. I’m not saying this is not the case, but the evidence for memory abuse are staggering.
Stuart Parmenter investigated this issue and his results are that this is all about memory fragmentation. As the blog post that I read that references this claims – Firefox doesn’t use a lot of memory, it just looks like it. This is of course a gross underestimation of the problem, because it doesn’t matter what the user perceives as high memory usage, but what the operating system perceives as high memory usage and as Stewart Parmenter’s results show – the operating system sees Firefox gobbling lots of memory and doesn’t care that the browser doesn’t use most of it.
The gist of the problem (if you don’t care to go read yourself) is that Firefox’s memory gets fragmented due to allocating and deallocating small chunks of memory, smaller then a page size – quite like a harddrive formatted for FAT does – When firefox needs more memory it allocates it in large chunks that can only fit at the end of free memory, thereby taking more memory from the operating system, but it frees the memory in small chunks here and there. The graphs at Stewart’s article demonstrate the results very well – you end up with Firefox using a lot of memory pages, but for each page only a very small part of it actually holds important information. The operating system can’t swap out “most of a page”, so the entire page stays in real memory even if only a few bytes are needed.
Update: It seems that the Firefox developers – at least Peter from above – are doing some work in trying to resolve the memory fragmentation issue, but its not clear how much improvement it at all will get in in time for Firefox 3. I’m not getting my hopes high.
I suggest reading http://blog.pavlov.net/2007/11/14/leaks-memory-we-never-forgot-about-you/ and http://blog.pavlov.net/2007/11/15/less-fragmentation-coming-in-firefox-3/ and rewriting your last paragraph 🙂
Ok, I updated the last paragraph – Peter claims some fixed are going to be in Firefox 3, but I don’t think there is any significant change in Firefox 3 beta (see also http://blog.pavlov.net/2007/11/19/firefox-3-beta-1/ ) and we don’t know anything about the release (I’m pretty sure Firefox would not get any major memory management work otherwise they’re not going to make the roadmap).
One problem I have with the opinions of Firefox developers is that they tend to characterize Firefox memory issues as insignificant (in the first link in your comment – [About larger caches:] It worked great but caused us to use a bit more memory), while at the same time characterizing fixes that result in small improvement to the memory problems as huge fixes that have a lot of impact.
I hope that version 3 will see a lot of improvement – especially for the many tabs use case, but as I don’t think that Peter’s use case of 20 tabs is large – I regularly have 20 tabs or more open in the browser (yay session manager!) and my girlfriend sometimes has over a hundred tabs at the same time – I also don’t think that the Firefox team would succeed in doing what they failed miserably at for the last 5 years: delivering solutions to users needs.
Stuart – I just noticed that its actually you that commented on my blog :-/ yea, I suck. But I still stand by all of what I said.
Anyway, thanks for coming over and commenting 🙂