Firefox 3 beats IE7 and Opera in memory tests, Mozilla claims

Plugging leaks and other memory reduction work pays off, say developers, in Beta 4

Work done to plug Firefox's memory leaks and reduce its RAM profile has paid off, two of Mozilla Corp.'s engineers said today, as they claimed that the newest beta of their open-source browser uses less memory than rivals such as Internet Explorer and Opera.

According to Mozilla software engineer Stuart Parmenter, who was instrumental in managing the memory reduction work, Firefox 3.0 Beta 4 uses less memory than IE7, Opera 9.5 Beta 1 and Firefox 2.0.0.12 while it opens multiple pages. Just as importantly, the newest beta of Firefox 3 does a much better job reclaiming memory when tabs are closed than its predecessor, Firefox 2.0.0.12.

"The terminal state of Firefox 3 is nearly 140MB smaller than Firefox 2. 60% less memory!" Parmenter wrote in a long blog post earlier this week describing the work of Mozilla developers in reducing Firefox's memory footprint. "[And] Firefox 3 ends up about 400MB smaller than IE7 at the end of the test!"

Parmenter and others -- "hundreds" of contributors, he said -- used a variety of techniques to trim the browser's appetite for RAM, including reducing memory fragmentation, moving to an automated cycle collector, fine-tuning memory caches and hunting down individual "memory leaks," the term given to problems that an application has in releasing system memory once it's not using it.

One way developers cut Firefox 3.0's appetite was to adjust the various memory caches the browser uses to boost performance, including an image cache, the page cache for speeding up back and forward navigation, and a font cache to improve text rendering speed.

Firefox now discards content in the back/forward cache after 30 minutes, Parmenter said, and uses a timer-based font cache, too.

That work and the other memory-related changes have been worthwhile. "There are a bunch of different reasons why it's good to address memory [consumption]," Parmenter said. "The more memory churn, the slower the program will be. And you can look at it as a memory fragmentation [problem], where you can end up with bad effects over time due to holes in memory. It's hard to reuse certain sections of memory, and [things get] slower as applications look for a new place to allocate memory."

"People may have a lot of memory [in their computers today]," acknowledged Mike Schroepfer, Mozilla's vice president of engineering. "But they're also running more. You want to be a good citizen."

Firefox has long been criticized by both its own users and those who prefer rivals' browsers as a memory hog and an application that has more memory leaks than a forgetful witness in front of a congressional hearing. The longer Firefox is open, and the more pages and tabs it opens, the larger its appetite for memory, according to the complaints. At some point, the load becomes big enough to degrade overall performance of the computer, or in some cases, lock the browser. Closing tabs doesn't reclaim the memory; only shutting Firefox down and restarting does.

But both Parmenter and Schroepfer denied that Mozilla had suddenly gotten memory "religion" and had only recently dedicated resources to the issue. "We've been working on this for a long time," Parmenter said, countering questions by some who have asked what took Mozilla so long to decide memory leaking was a problem. "[Memory] has always been important in the back of peoples' minds, even in the early days. In Firefox 2.0, there was definitely a trend toward smaller memory." But Mozilla hesitated to implement memory reductions in Firefox 2, he said, because it was already in production.

Schroepfer chimed in. "We've been investing in [memory consumption work] for quite a while, and some changes have been worked on for more than a year. What you're seeing now are the final results of that work."

Last November, after Christopher Blizzard, a member of Mozilla's board, tied reducing Firefox's memory consumption to the push to put the browser on mobile handsets, it seemed work intensified on plugging leaks. And earlier this week, Schroepfer noted that performance improvements in Firefox 3.0 would carry over into the move on mobile.

"We're really excited about how this looks in mobile, but we would have done it anyway," Schroepfer said today. "We wanted to do it on the desktop."

Parmenter created the memory test -- he dubbed it a "stress test" -- that loaded 29 different pages through 30 windows in 11 cycles, for a total of 319 page loads. At the end, all tabs but one were closed and the browser allowed to "sit for a few minutes" to see how much, if any, memory the system reclaimed.

Although Parmenter and Schroepfer ran both Apple's Safari browser (and the in-development nightly builds from the WebKit project) and Microsoft's Beta 1 of Internet Explorer 8, but both were unable to finish, crashing at various places. Opera's 9.5 Beta, code-named Kestrel, however, was able to complete the tests.

"[Opera] peaks around 240MB and doesn't free up any memory at the end, so ends at 240MB," said Schroepfer in a comment to Parmenter's original blog, the Opera test prompted by numerous readers' requests. "Performance during the run is similar to Firefox 2.0.0.12 but higher than Firefox 2.0.0.12 at the end. It is significantly higher than Firefox 3, which peaks around 220MB and ends at 85MB."

Parmenter admitted that the test was just one of any number of possible benchmarks, and said Mozilla would be coming up with other tests. "I don't think we're done in memory," he said. "We need more tests to show more usage patterns. We need to find tests where we don't look as good [as the one published]."

And there is more memory work that can be done, Parmenter said. "I don't think we're done in memory. There's additional work to look at how we handle caches, for example."

Firefox 3.0 Beta 4, which was released last Monday, can be downloaded for Windows, Mac OS X and Linux in 36 languages from Mozilla's site.

FREE Computerworld Insider Guide: IT Certification Study Tips
Join the discussion
Be the first to comment on this article. Our Commenting Policies