Categories
Firefox Memory consumption MemShrink

Debunking A Misconception About Firefox Releases

There is a common misconception that every time a new release of Firefox comes out Mozilla claims “this is the one that fixes the memory consumption problems”.  I see this misconception in action all the time.

The Misconception in Action

Here are some recent examples.

Reddit example 1:

NEXT VERSION OF FIREFOX IMPROVES MEMORY USAGE

Holy crap!!!

Oh wait, I feel like I’ve heard this before. Oh yea, with ever. single. new firefox release in the last 3 years. Every one.

Reddit example 2:

“Firefox 14 fixes the memory leak problem!”

“Firefox 13 finally addresses the leaky memory issue!”

“Firefox 12 – better on memory. No more leaks!”

“Firefox 11 – finally solving the leaky memory problem.”

etc etc etc

I’ll believe it when I see it.

Reddit example 3:

Firefox has finally fixed the add-on memory leak for about 10 versions now.

Hacker News example 1:

I’m not sure when Firefox got so memory-hungry and leaky, but it’s the single reason I keep jumping around to Chromium and Opera. Really, really hoping that this time is for real. It’s not the first time a blog post like this has been posted by Mozilla.

Hacker New example 2:

How many releases of firefox have we had now that claim to have fixed its memory problems? I make this at least four, which is a few too many for me to believe it this time.

Ars Technica example:

“Firefox 15 introduces a new optimization that can radically reduce the browser’s memory footprint…”

Haven’t they been saying this since Firefox 11?

This drives me crazy, because it’s simply not true.

Debunking the misconception

I looked at the announcements on the official Mozilla Blog for all the releases between Firefox 4 (March 2011) to Firefox 15 (today):  4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15.  Only three of them even mentioned the word “memory”.

  • Firefox 7.  The headline says “Mozilla Firefox Significantly Reduces Memory Use to Make Web Browsing Faster”.  The text includes: “Firefox manages memory more efficiently to deliver a nimble Web browsing experience. Users will notice Firefox is faster at opening new tabs, clicking on menu items and buttons on websites. Heavy Internet users will enjoy enhanced performance when lots of tabs are open and during long Web browsing sessions that last hours or even days.”
  • Firefox 13. The text includes: “Firefox loads tabs on demand when restoring a browsing session to more quickly get you to Web pages. Firefox first loads the tab you are currently viewing, then loads background tabs when you click them. It’s an improvement that makes Firefox start faster and use less memory.”
  • Firefox 15. The headline includes: “Firefox Now Uses Less Memory to Make Browsing Faster”.  The text says: “Firefox makes your Web experience faster by reducing memory usage when browsing with certain add-ons. The improvements make browsing smoother and more responsive.”

That’s two major mentions of memory consumption, and one minor mention, in twelve release announcements.  The major mentions were warranted — Firefox 7 greatly reduced memory consumption for Firefox itself, and Firefox 15 greatly reduced memory consumption in many cases for users with add-ons.  And the claims about improvements are clearly qualified to indicate in which circumstances they will be noticed.

But what about the release notes?  After all, although they are less prominent than the announcements on the Mozilla Blog, they’re arguably a more official description of the changes in each release.  Of the twelve releases since Firefox 4, only four of them had release notes that mentioned the word “memory”.

  • Firefox 15: “Optimized memory usage for add-ons”.
  • Firefox 8/8.0.1: “Improved performance and memory handling when using <audio> and <video> elements”.
  • Firefox 7/7.0.1: “Drastically improved memory handling for certain use cases”.
  • Firefox 5: “Improved canvas, JavaScript, memory, and networking performance”.

The Firefox 7 and 15 mentions match the release announcements.  The Firefox 5 and 8 mentions are minor.

At this point it should be clear that this really is a misconception, with no basis in fact.

What Causes the Misconception?

My best guess is that Chris Peterson nailed it with this comment.

I think the press (overly) publicized the add-on leak fix as it progressed through Firefox’s 6-week release pipeline (Nightly -> Aurora -> Beta -> Release).

In other words, it’s caused by the combination of Firefox’s rapid release schedule and the current intense interest in browser development in the tech press.

For example, a random tech press reader may have heard about the Firefox 15 add-on leak fix multiple times on different sites:  on May 8 shortly after it first landed, then again on July 19 when it entered Beta, and then again on August 29 when it was released.  (These articles correspond to increasingly prominent blog posts from Mozilla employees and Mozilla itself, such as Kyle Huey’s personal blog, the Mozilla Web Developer Blog, and the official Mozilla Blog.)  If that reader wasn’t paying close attention, it’s easy to see how they could end up with this misconception.

It’s an interesting and difficult problem.  I think it’s reasonable for Mozilla employees and Mozilla to announce important changes multiple times, at different stages of development, on different communication channels.  I also think it’s reasonable for tech press sites to report important changes at different stages of development (especially when you consider that each individual site might only mention a change once or twice).  And I don’t think it’s realistic to expect readers to remember which in-development version of Firefox it was that contained some change that they read about two or three months ago.

My only idea for a solution is ad hoc education.  So, if you see someone holding this misconception, please point them at this article!  Even better, if you can determine how they came to believe it, please let me know.

27 replies on “Debunking A Misconception About Firefox Releases”

For a while, people were desperate for positive news about Firefox. Memory management being one of the biggest bugaboos of the browser, any news from Mozilla – a developer blog post is news these days – “sold copy”.

Once the memory management issues become passe, it will be snappiness, or support for standards, or something new that Firefox needs to play catch up on. In fact, if you read the HN article, there is already talk of snappiness being the reason people switched to Chrome.

The discourse in the forums and on HN/Reddit is more positive and encouraging these days. This was not the case until a few months ago; being a Firefox supporter in 2011 was rough. The dark days, they are almost over!

It might not have been a big deal in the release announcements, but there *has* been plenty of noise over time on developer blogs about “current release+1” containing fixes for some of the memory issues, and sites like https://areweslimyet.com/ highlighting the efforts.

Anyone who follows those blogs (or more likely, hears about them second or third hand) is going to be under the impression that Firefox is constantly trying to reduce memory use, then disappointed if the next release doesn’t seem to help much.

Excellent post, and nice work in going through all the release announcements and notes for all those versions!

How so? It’s all arbitrary.

How do you determine how significant a memory improvement is? 50 MB? 100 MB? 250 MB?

How do you determine how much an add-on platform update will break existing add-ons? 1%? 10%? 50%?

However, I am more partial with a time-based version number, but it seems that idea has been set on the backburner.

i agree, because no one outside those reading p.m.o (and possibly even most of us who do) understands *anything* about firefox version numbers.

i strongly thing a simplified, user-friendly, calendar-based versioning woud be really help messaging, for example seasonal release (spring, summer, fall, winter 2012) versions, with possible theming of the PR, blog posts and maybe even Firefox button color.. 🙂

I was about to point you to the memshrink blog posts, then I realised you’re the author!

I know too much about Mozilla to think like a typical redditt/hacker news/ars reader, but my impression has been that each recent release of Mozilla has included significant memory improvements (you could call them fixes, but memory usage isn’t a problem than can be ‘fixed’). Individually these are often relatively minor, but together they add up to significant improvements over a year. It’s a fundamental problem/benefit of the rapid release cycle – Mozilla will be in the press more frequently, meaning the stories will often be the same.

As for how to fix the problem of reports on alpha/beta changes, maybe encourage people to start their blog post with something like:
“This change is currently part of Firefox X, due to be released dd-mon-yyyy”

Systematically mentioning the feature’s status in the release pipeline would help. For a future feature, mention “should be merged in firefox <release number>, which is expected on <month of year>”. Your text that got quoted on the hacks blog mentions a version number, but no expected release date. Without context people would expect it to be a final release. Kyle’s blog post is worse, it makes no allusion at all to the merge status or the release status.
When releasing, mention that you did a release (and maybe mention a date, or a version number, or at least a reminder that some of the features have been in preview for three months or so). The final mozilla blog post was strangely non-explicit about that.

The official announcements deliberately avoid mentioning version numbers. It’s part of the “version number doesn’t really matter, so long as you have the latest one” idea.

So that could be a factor… but I suspect most people are not reading the official announcement, but reading reports in the tech press. And tech press articles almost always mention the version numbers explicitly. Therefore, I’m not convinced this is a significant factor.

*sadface* (previous response to Manoj Mehta)

@nnethercote

Your efforts to educate users about positive changes to firefox is both inspiring and needed. However some of your comments on reddit made it seem (to the uninformed reader) that you were contradicting the existence of memory fixes themselves, not asking for evidence that ff had falsely boasted of mem improvement.

I would argue that even if the specifics are misunderstood, it doesn’t matter that much. Many users will only encounter this information once on one of these sites. Since fully educating the internet about subtleties will always be a losing battle, I think any positive news is good news. Even if the op or blogger appears skeptical due to imaginary past “claims”.

The most important message for the regular internet user should be simply: “firefox is improving in many ways, especially memory usage has undergone significant improvements”

As long as this message gets out, the details are never going to be that exact. But I understand it must be frustrating to these discussions bereft of your nuanced understanding!

It’s all very simple to me:

I don’t give a damn.

I leave Firefox open for WEEKS and it’s eating up 1,4GB of RAM with about 50 tabs open, and it still only crashed on me once a year. And when it does, I don’t care cause everythign will be back to where it was when I restart.

I don’t give a damn.

I understand where you’re coming from with this article. Officially, there haven’t been many mentions of memory improvements. There was no official reason to expect major memory improvements in the releases beyond those that you list above.

As long time users who’ve been experiencing the memory leaks for years, every new release has been an opportunity to cross our fingers and hope that changes in this release would finally slay the leaky dragons. This is especially true for those of us who use a lot addons. We read the release notes and didn’t see a marked improvement in our issues. With dedicated resources, you and the MemShrink team have finally been able to track down and fix our biggest headaches (Sincerely…thank you for that). The transparency that you’ve brought to this process has helped combat that fingers-crossed mentality. In time, I think more of the most vocal will become more aware of your efforts through this blog and through using the improved product. Especially after the release of 15, I think there will be less unrealistic wait-and-see that has lead to a lot of user frustration.

Understand your post. I am on Firefox 15. Nonetheless, memory usage still grows to over 1GB for me over the course of a day, with about 65 tabs open, about half of them loaded (the rest background unloaded). I have about 10 add-ons running. Memory use never seems to go down, just slowly up as the day progresses. How do I go about determining what causes the problem? I’ve tried watching for patterns, and I’ve stared at about:memory a bunch. I’ve been waiting for Firefox 15 to “finally” fix what I assumed was the last remaining source of leaks… only to be disappointed. Any ideas?

The problem is that the memory footprint is increasing without an increase in the number of tabs (therefore, a “leak”). It started closer to 600M, then grew to 1.2G over the course of the day. I imagine that another day or two of running, and the memory footprint might exceed 2GB and cause Firefox to crash. The browser stuttered and became more choppy as time went by as well. After a few hours of running, I can’t effectively use the Awesome bar to search, because lag causes some characters to be missed if I don’t pause between characters.

It might be a particular site that’s causing it; the fault could be with Firefox or with the site. It could also be an add-on; the Firefox 15 change prevents the most common cause of add-on leaks but add-ons can still leak in other ways.

I’d be interested to see about:memory at the end of the day. That’s the first thing to look at — can you email it to me?

Forgive my lack of understanding when it comes to web architecture… how could a site be causing it? Is there something I should look for in a site that would cause memory use to constantly increase with that tab open but otherwise unused?

Sites that contain things like javascript aren’t simply documents: they’re programs that run within the browser. Like all programs that allocate memory dynamically, they can leak.

Unfortunately, it’s often challenging to find leaks.

As far as I know, when people complain about Firefox as a whole, the single most common problem is the bloat/leaks/poor memory usage, and consequent poor performance. So when a new release comes out, that’s a hot point that people are going to pay attention to.

The official release notes are just a trivial bit of marketing. They’re a bit of a guideline for what new stuff is in place, but they are not the sole definition of what people are interested in, nor should they be (otherwise you could say that every single article about anything should be nothing but a copy/paste of whatever press release the company decided to put out). Every blog post of any dev anywhere (including this entire blog) that addresses actual user issues like memory usage is a source for a claim of improvement in whatever version it relates to. Hell, if someone is really serious about a full accounting of the changes made, they can go through the bugs in bugzilla, which is about as official as you can get, and they certainly detail plenty of fixes for various memory issues.

Making the claims you did based solely on the pitifully myopic view of the official release notes as your sole justification just makes you look bad.

I suspect that the people who pay close attention — who read my blog, other Mozilla blogs, bugs in Bugzilla, etc. — are not the people holding this misconception. These people who pay close attention are likely to be able to tell the difference between a small improvement that gets a little publicity and a big improvement that gets a lot of publicity, and they are likely to be aware which version the big improvements are in.

Sure. I left it on overnight and the footprint grew from 900MB or so, to 1.2GB or so. I can’t find your email address on this site, but you should be able to see mine as I entered it with each post. Can you email me your address and I’ll reply?

@mz, the question is if the memory useage keeps climbing forever.

I have lots of tabs open (somewhere around 30 or so windows, probably a couple hundred tabs, about:memory lists 14 names window objects and then has a category labled “332 tiny”)

When I first start firefox it says that it’s using ~700M, after running for a few hours it climbs to ~1.3G (horrible leak right?), but after running for a couple of weeks it’s still only at 1.5G

at this point, firefox is a mini OS, it doesn’t laod everything immediatly, it loads things as they are needed, and as noted above, sites can make things worse (javascript, updating images without removing the old image, stupid CSS tricks)

Ok, a correction, if I go through and do a reload on all tabs for every window, my usage goes up to 2.3G for 338 top level window objexts (I closed a few)

Comments are closed.