Firefox – new release cycle observation
So working as I always do with Firefox – you know, several windows, kazillion of tabs – I have lately discovered that my PC was running slow nearing the end of a working day. Now, for first 100 times, I just ignored the fact that my 3,33 GHz Core i5 Workstation with 4GB of RAM running windows XP shouldn’t be running like this. At least it was not a week or two ago. Yesterday however, I had quite enough of it and decided to consult task manager and see what is eating up my RAM. Two processes stood out:
a) Visual studio (three instances of it to be exact) that ate up about 700MB of RAM and
b) Firefox 6 (two instances) eating up a nice sum of 520MB of RAM.
Whoa! There is a lot to be said of the browser that’s eating up 520MB of RAM, however, it could as well be all the tabs and all plugins I am using. So, I closed all tabs in one instance which led me to a awesome save of 10MB. Closed the second instance and all but one tab in first instance got me yet another 10MB memory save now marking Firefox as a 500MB process for handling one single browser tab. After another hour of doing nothing with the browser, it dropped to 490MB. Nice.
This looked a lot like a memory leak or someone trusting garbage collector just a bit too much. Nah, it must have been all my plugins (5 in reality: FireBug, Web Developer, FireGestures, TabMix Plus and Live HTTP Headers. So, I turned them off. Starting Firefox without any plugins. Opening browser with a blank start page took 69MB of RAM. Just loading arstechnica.com caused it to take yet another 20MB. Now, one would think that that was it: 89MB for 1 tab with a website opened. Nope. Reload the same site and it suddenly takes 95MB of RAM and stagnating. So, the difference of 6MB on a page reload and I was pretty sure garbage collector won’t clean this up. Non-the-less, I decided to leave PC working overnight with just this one page loaded.
Results next morning were staggering. And not in a good way. In the morning, the same browser window with same page that never reloaded consumed 150MB of RAM! That is a huge memory leak of 70MB in some 6 hours.
Now this got me thinking. I last seen such memory leak in Firefox 3 early releases. And that one got fixed by a 3.2 version. But that was when Mozilla was sticking to old release cycle. These days, release cycle is reduced to 8 weeks. Compared to most others, I fail to agree with this policy and this memory leak is the precise reason why. If you are releasing a new version every 8 weeks, there is not enough time to clean up bugs. And that can mean only one thing. That old bugs are transported to newer versions.
Now, I bet that to some marketing guy, the 8 weeks deadline seemed a good idea. After all, every 8 weeks, we get a discussion if it was really necessary to create a new version for a browser with less changes than a 3.x edition used to have. And talk is good. Right? Wrong. Bad publicity kills reputation, which kills market share, which can kill a product and I am seriously wondering if Mozilla is aware of that.
August 25th, 2011 at 19:24
Bah, talk to us when your Firefox is consuming over 1 Gig memory (happens to me often lately). The multi-window/multi-tab memory leak has been going on for quite some time, prior to the new release cycle. However, Mozilla developers have identified a fix (increasing GC frequency) that will address mem usage by the JS engine which is especially aggravated in the multi-window/multi-tab, left-open-overnight scenario.
The fix was late for the FF6 process, but is slated for FF7 (target date of Sep. 27). This actually shows the benefits of the rapid release because otherwise, it would have needed to be slipped into an emergency security fix or would have waited much longer for the next release.
August 25th, 2011 at 20:32
500MB is a lot, when you are running 2 visual studio instances, lotus notes and 2 instances some database access tool. 😀
I really don’t see how this is a proof that rapid release is better? In the past a patch came about once every two weeks and now once every 8 weeks. And you said it yourself. This leak is from v5 or even v4. So, they failed to fix it by v6? That is from 8 to 16 weeks. In the past, this would be sorted in 3 to 4 weeks.