I’ve seen quite a few posts lately based on the memory fragmentation work that I’m doing with titles such as “Fixing Firefox’s memory issue becomes a priority.” Others have claimed that this work is a result of Mozilla’s new focus on mobile. While I’m glad that people are paying attention to our memory work and offering great suggestions, let me say: Memory issues have always been a priority.
Since I started working on the project in 1998 we’ve always had a focus on keeping our memory footprint small and keeping leaks to a minimum. Early in the development cycle for each release we’ve set goals for memory and performance. We always set our bar under the previous release. I’ve found that developing desktop software is a pretty constant balancing act between performance and memory use. We’re always making trade-offs and we try our best to chose the things that will work best for the largest set of users:
- Back in 2001 when I rebuilt our imaging library, I made several decisions to use more memory to store images results in faster rendering; optimizing for memory use reduces the speed at which was can display pages. We’ve looked at these issues many times over the years to make sure they were still correct. Recently we’ve adjusted that behavior to not keep full uncompressed images around as long which will result in memory savings but will cause initial scrolling to be a bit slower on documents you haven’t accessed in a while.
- In Firefox 1.5 we added a feature called the back/foward cache which keeps documents in your recent history that you’ve navigated from in memory. This was done to significantly speed up hitting the back button. It worked great but caused us to use a bit more memory. We made sure that it was only using memory your computer wasn’t already using, but again, it’s an example of a trade-off. We started off with a pretty high number of pages that we kept in the cache and have continued to adjust that number to keep a more limited set of pages to help prevent unnecessary bloating. We’ve also started expiring these pages over time so that you don’t keep pages around you probably aren’t going to use.
With the popularity of extensions rising, we started hearing complaints about memory leaks. We took these reports pretty seriously and have spent a lot of time investigating what is going on. A lot of work has gone in over the last few years to reduce these leaks. Most of our early testing was around the browser, without extensions. Our investigations showed that certain extensions in caused a pretty bizarre class of leaks that were pretty difficult to fix given the architecture in Firefox 2. We fixed as many of them as we could in Firefox 2 but some we were unable to fix. In Firefox 3 some Really Smart People (graydon, peterv, dbaron, etc) have built this thing called the cycle collector in to the core which addresses many of the leaks that we were seeing from extensions (as well as leaks from other places that were of the same class). Our extensive testing shows an occasional leak here and there and we are working to fix those, but in general we aren’t seeing many leaks anymore.
It is only after we’ve gone through so many leak fixes and done so many other memory reduction fixes that we’ve needed to a deeper look at what is going on under the hood. We’ve long had suspicions that we were being hurt by memory fragmentation, but it wasn’t until recently that we had built good tools to fully diagnose the problem.
I’ll assert here that the way people use their browsers has changed. When Gecko was originally designed back around 1998 people had one, maybe two browser windows open without tabs, and they certainly didn’t have any extensions installed. I look at my browser windows now and I’ve got 3 browser windows open with a total of about 20 tabs open. That is 10x the number of documents open at once!
With the change in how people use their browsers, there is no doubt that they’re going to use more memory. We’re doing everything we can to minimize the impact of having lots of documents open. Many people are trying to shave off bytes here and there. Just in the last week we’ve removed over 200 thousand allocations just from startup and first page load. We’ve got a great community and people eager to solve these problems. We’re now equipped with data and ready to fight this battle.