Update: If you got here because you just read an article about this issue, maybe you should just go read Stuart’s most recent post instead of this one.
For a long time there have been a lot of complaints about the memory usage in Firefox and anything else that used the Gecko engine. And looking at the numbers for what Firefox would use for memory, they seemed valid. But on the other side of the story, I know that the Mozilla team has been pretty diligent about fixing memory leak bugs. Allocations are tracked closely across checkins and leaks are fixed when they are discovered. So why the different perceptions for what people were seeing in the field and what the programmers were tracking during a development cycle?
As Mozilla starts down the path to running in the mobile space we are spending time looking at memory pressure issues more closely. Stuart and Vlad spent time looking at the behavior of the allocator during some simple tests and it sounds like the early data suggests that Mozilla really doesn’t leak that much memory at all. But it does thrash the allocator pretty hard and that’s what causes the perception of memory leaks. There’s a lot more information in Stuart’s post of course, including some good visualizations.
Over the next few months it will be very interesting to see what happens with both memory usage and perceived performance especially as we connect those numbers to a successful mobile strategy. I’m sure Stuart will continue to post updates as he goes along and as tools become available to be able to spread this work out to others. For those who are trying to use the engine from Firefox in a mobile device (like the Nokia N810, for example) this work will be very useful. Go Stuart!
-
I think the key issue is not how much memory does GeckoZilla use and whether X amount is reasonable, which is how Ben Goodger tried to respond to the early criticism. Rather the issue is how a system performs if a GeckoZilla application is using X amount of memory.
From my own non-technical perceptions, it appears that any application on Windows XP that uses more than 10-15% of total RAM, will start grinding to a halt.
I have a system with 1 GB or RAM. I’d be more than happy for a single GeckoZilla application to dynamically use up to %75 of that, depending on how many other applications I am running. I still want some memory reserved for overall system use and that would be my %25.
Unfortunately Windows does not seem to handle the use of more than %20-40 of available RAM before it starts to crawl.
-
i have a fujitsu p1120. it has 223mb usable ram and a 800mb crusoe processor. i also have very recent 160gb hitachi hard 5k100 drive with a 4gb swap partition right after linux (which is 10gb in size), so swap access should be very quick.
my complaint with firefox is not that it leaks memory. the kernel will just swap out all the memory you leak, and thats the end of that. my problem is page footprint. if i have seven or eight pages i am trying to access, firefox cannot keep that 160kb of html,css, and javascript in the 120mb of memory left for firefox after X, postgresql & lighttpd. your recoculous fragmentation issues are part to blame for overinflating the number of pages held & the memory footprint, but what if anything is being done to directly reduce the size of what needs to be stored in memory for a page?
thankfully they seem to double the amount of memory on mobile devices pretty frequently, i’d say that’d put the n820 in line for almost being a tolerable firefox experience.
-
rektide, I’d be interested in the pages you’re seeing problems with. Doing a head-to-head comparison with other rendering engines (e.g. Opera, IE6/7, khtml, Safari) typically shows them all needing pretty similar amounts of memory to render typical pages. More often than not, Gecko is using less memory than the others (in fact, parts of layout are overoptimized in the “use less memory” direction).
So if there are pages where Gecko uses significantly more memory than other UAs, please let us know! That’s the first step to improving memory usage on those pages.
-
> So why the different perceptions for what people were seeing in the field and what the
> programmers were tracking during a development cycle?Perhaps the programmers were measuring the wrong thing – low level stuff that
algorithmically would not qualify as a “leak”, but from a higher level point of
view, are wasted anyway. Consider the multi-YEAR open bugs regarding excessive
image memory use within the mozilla process and the window server. Things are
only slowly improving. -
I don’t know if Mozilla actually leaks memory, but it’s performance certainly degrades with use. My browser is nice and snappy right at startup, taking 600 MB footprint. After 3 days of intensive use, it’s up to a 1.1 GB footprint (no big deal) but it’s often locks up for multiple seconds. Pretty much every 5th click in a Moz window results in 100% CPU for 4 seconds while the GUI is totally frozen. Then, after the 4 seconds, Moz feels snappy again until you click a few times and it freezes up again.
To get around this, I pretty much kill & restart Firefox daily. Yes, it feels disturbingly like Windows in the old days.
This has been a 100% reproducible problem since the early 1.0 days. Given Gecko’s glacial development and ongoing hassles, I really think WebKit is probably the way to go for mobile devices. If anyone disagrees, I’d really like to hear why!
-
Remembering this fight from 10 years ago at Spyglass.. the perception isnt about leaked memory.. as much as how much memory is used period. Is
the average person getting more stuff from 10 years ago when his ‘bloated’ browser was 16MB than his current 128MB resident memory browser? Why is it that one got a pretty good browser at 1MB [The DOS Spider browser nand QNX one] but now must have 100x the memory and 250x cpu requirements to get more fonts and some layout changes?And due to the fact that the browser is all one mass of processes.. ti is very hard to show the ‘lay’ programmer/user how much each section is using and that this is what one should expect for XYZ feature. If I remember correctly the QNX browser was broken into multiple sub-processes that allowed you to turn off things you didnt need/want and also deal with various oops. If netconnector died.. it didnt kill the rest of the browser but was restarted by master process [I know that the Spyglass embedded browser was going this way to deal with some items the industry wanted in 1996 or so]
-
In our experience WebKit often uses more memory than Gecko for rendering similar pages. Whether or not it suffers from the same level of fragmentation issues that Gecko does is something that we’ll probably look at but we know that we often do a better job with memory management.
As for why Gecko might be more appropriate for Mobile devices? If you look at all of the issues in the choice of technology that’s out there there’s one overriding fact – flat out more of the web works in Firefox and Gecko than in WebKit. And Firefox has a growing user base and a well-known brand. That has real value in the market place. That along with the increasing performance of the engine (the new work being done in FF3 already makes a lot of things faster) and the work that we’re doing with memory means that the perceived advantages that WebKit has today will be pretty marginal in a very short period of time.
-
So basically what you’re saying is that you didn’t really care about the problem until you went into the mobile space, where the problem was going to lose you money.
Memory leaks, fragmentation, or whatever the real problem is has been a problem since 1.0. Everyone has known it, it’s just not been acknowledged. But no one wants to work on hard things, only fun new bloat like the new bookmarks system.
Well I’m glad financial matters finally pushed the issue.
-
Pingback from » Fire the Fox farry.nl on November 12, 2007 at 12:22 pm
-
I still suspect extension-triggered problems are a pretty big part of the perception problem. It would be interesting to try and figure out some way to test this hypothesis.
-
I agree with sb that there are serious memory management problems. I routinely have many windows opened (up to 20), containing up to 20 tabs. Leave it open for a few days and Firefox memory usage goes through the roof.
On my previous system I even added a 20 GB swap partition because of this constant memory increase. There are some deeply rooted issues in the Mozilla code base and it doesn’t look like they will be solved any time soon.
The only thing to do is kill the browser and hope it can restore you previous session completely. Maybe there’s an extension to do this automatically, I’ll have to look into that.
-
Yeah, extensions sure do play a huge part in performance and leak issues. I know that we’ve been looking at tools that might inform developers and users about the impact that various extensions have on the browsing experience. I don’t know how far along those are, though.
Karl, looking at memory is something that we do all the time. I’m not sure if we’ve looked at fragmentation in the past as a specific issue but we’re certainly looking at it now. Mobile is a factor, but it’s certainly not the main driver. We know that this have a positive impact in both desktop users and mobile so it’s worth the investment.
And we know it’s hard. We’ve been working on a huge number of hard problems. Take a look at the work that’s going on in ES4 or the work that roc has been doing or the tools that we’re looking at to move our code base away from the reference counting system that hurts us in so many ways, including memory and performance. Those investments will help us over the long term and are worth the effort.
-
> I agree with sb that there are serious memory management problems. I
> routinely have many windows opened (up to 20), containing up to 20 tabs.
> Leave it open for a few days and Firefox memory usage goes through the roof.That’s 400 pages! Of course that requires some memory.
> On my previous system I even added a 20 GB swap partition because of this
> constant memory increase. There are some deeply rooted issues in the Mozilla
> code base and it doesn’t look like they will be solved any time soon.What specific things do you see that are rooted in the code base that mean that they won’t be solved? We know that reference counting is hurting us, and we are executing against plans to work on that. We know that fragmentation is and issue and we’re looking at ways to mitigate that as best we can. (Although fragmentation is a problem that _all_ programs suffer to some degree it’s just not that visible.) We are closely tracking performance of FF2 vs. FF3 and we already know we’re doing better in a lot of ways. We know we do better in memory usage than WebKit does today. What specific things have we missed in the big picture that we can’t possibly fix? Such fear mongering doesn’t really have a place if you don’t have something specific to say about what we’re missing.
> The only thing to do is kill the browser and hope it can restore you previous
> session completely. Maybe there’s an extension to do this automatically,
> I’ll have to look into that.You don’t need an extension. Try Edit -> Preferences -> Main -> When Firefox Starts -> Show my Windows and tabs from last time.
It’s usually the first thing I do when I do a new install. I leave tabs open all the time and just leave them there across restarts. It works very well.
-
The memory problem is easy to reproduce. Go to http://www.buienradar.nl/ and leave your browser as it is. The page will refresh automatically and the memory consumption of firefox will rise and rise.
Look at your taskmanager in the process tab and you will see the firefox.exe process growing. Wait a few hours and a few hundred megs is no exception.
There is a bug and it has been there for ages. Nobody seems to listen.
Still a FF fan ;)
Boonie Dufsnuf
-
Pingback from Hardware 2.0 mobile edition on November 12, 2007 at 4:21 pm
-
Karl Shea Says:
> So basically what you’re saying is that you didn’t really care
> about the problem until you went into the mobile space, where
> the problem was going to lose you money.I agree with Karl completely.
-
> What specific things have we missed in the big picture that we
> can’t possibly fix? Such fear mongering doesn’t really have a place
> if you don’t have something specific to say about what we’re
> missing.First of all I want to say that I’m a distribution developer and am regularly building newer releases on multiple architectures.
I appreciate what you’re trying to achieve with Firefox and you’re doing very well, particularly in some of the other European countries. Usage in the Netherlands seem to be behind, but people here are addicted to Microsoft technologies.
I didn’t intend to spread any fud or something. What I’m presenting is that I’m a heavy Firefox user on Linux. Maybe I’m doing insane things with it, but that’s because I trust it to be dependable and stable, just like the rest of my distribution.
I’m running my server with 1 GB RAM 24/7/365 and have a VNC session running on it. Firefox is running within that session. There’s nothing wrong with the VNC code that is related to Firefox memory consumption increasing over time, as far as I know.
I have very few extensions installed, only Quickzoom and Adblock Plus and would remove them if they were installed with Firefox by default in some way or another. I also have Adobe Flash 9 and Sun Java 1.6.3 installed, which admittedly could cause issues.
Hopefully Gnash will be usable eventually and the OpenJDK will be completed so both technologies will be usable with completely free sources too. Then you can inspect all source code, both Mozilla’s and the others’, to see where the problems are.
You could create tests that monitor for memory consumption with such a usage pattern and improve your code base. I thought this was about creating the best and most useful software using best software engineering practices.
If these plugins cause memory usage to increase over time, the code base should include some mechanism for killing them off, without taking the browser down. That’s what I call robustness.
I might be setting the bar too high, but that’s just what I expect from my software. I’ve long given up on closed source software where there is a usable free alternative. Now I only want the free software I use to be the best it can be.
Please correct me if I’m wrong and you have other views/priorities.
-
Well.. run http://www.meebo.com for couple hours and you will need to restart the firefox browser.
May be it is caused by firebug…
-
I’m not trying to start an argument, as I’m glad that you guys are looking into the issue.
But blaming extensions is a cop-out. That’s what every developer says when this issue is brought out.
I ran Firefox extensions-free for a couple of days with normal-to-light usage on my XP pc. After 3 days, its memory usage had climbed to 700MB, and performance slowed to a crawl.
That’s completely unacceptable, and has nothing to do with extensions. It has to do with a codebase that has had this problem since before 1.0.
Don’t get me wrong, I use Firefox over any other browser, but it’s disheartening every day when I have to kill the process and use restore session.
-
I wasn’t blaming extensions as a cop out. We get a lot of reports of memory issues and a lot of them turn out to be issues with various extensions. We’re not blaming. We’re just trying to make people understand what is the cause. That’s why I said that we were thinking about making tools that help extension authors figure out if they happen to be causing leaks. We have a couple of thousand extensions to firefox and it’s unreasonable to assume that we could test all of them, or even in combination. We need to be able to distribute that information out to the developers themselves.
-
@Boris
http://my.opera.com/desktopteam/blog/
Try that out( real world usage ) and tell me which one uses more ram, feels more responsive.
Also, check this Android Emulator vs Firefox memory hogging:
http://img260.imageshack.us/img260/4300/ffvsandroiddg7.pngfunny stuff.
-
Having thought about my issues again over the night, do you have any torture suite to test the hell out of the Mozilla code base? I’m willing to run it on my various boxes on several architectures. If you can collect any meaningful information that way, it could help with development.
But you should already have much more powerful systems in your build farm. Firefox’s behaviour on small systems where it’s shut down every few hours or every day might not be a good indication of how it performs on large systems with lots of cores and gigabytes of RAM for prolonged periods of time.
I’ll probably have such systems next year but not at this moment.
-
We have systems both large and small for testing and we do use them. I’m wondering what we can do testing with on large systems. I know that Stuart is doing testing on his box and building out some tools so we’ll see what happens.
-
Of course that Android vs. Firefox memory hogging doesn’t describe what’s actually loaded in each one. :)
-
My biggest problem with Seamonkey on Linux is cause by the flash plugin. After a certain amount of time, it causes X to use huge amounts of VM and X starts thrashing. When it happens, it’s because I use the right-click menu on the flash plugin. Other than flash, Seamonkey runs great and doesn’t hog memory like it used to.
-
Pingback from Tuesday Tabs on November 13, 2007 at 2:03 pm
-
About using memory Opera is the best one.
You can open up to 40-50 pages only by 256 MB ram.
It is impossible in explore (as you know after a time toolbar of explorer disappears.Then it freezes.)
Firefox more stable than explorer but after 20 pages it fulls up memory.I am using three of them. Everyone has an advantage.
Firefox with it’s extensions is the best. Only the problem is memory usage.Firefox developers may be asked to Opera developers how to made this :)
Finally check NEW opera mini 4.0. Again Opera team make a great job. -
Boonie Said: “The memory problem is easy to reproduce. Go to http://www.buienradar.nl/ and leave your browser as it is. The page will refresh automatically and the memory consumption of firefox will rise and rise.”
I’ve left the latest Firefox 3 build open with that page visible for two hours without any increase in memory usage (84 MB). Perhaps the problem is not as easy to reproduce as you think. Maybe others can try it and see if they see the memory use increase. Anyone else who believe to have a demonstration of a memory problem is welcome to share, and I’ll see if I can observe any problem. Thanks.
-
I agree with sb that there are serious memory management problems.
-
Juste dont forget that Firefox is not the only one which have probleme to manage ram…
simple exercice is to try whatching streaming video inside IE7…
after 10 video you can rich like 500Mo of ram only for IE7…managing ram is the most important try for next genetration of software.
-
lmjabreu, I routinely try Opera. After all, it’s one of our major competitors. I agree that it’s more responsive and faster than Firefox; in fact I tend to use it as a good benchmark to shoot for when working on performance bugs.
That said, memory usage is a tossup. For example, on a Bugzilla bug list (one of the larger pages I load daily) Gecko uses less memory than Opera last I checked. There are various other pages where Gecko is leaner, and still others where Opera takes less memory. All this on Linux. Memory usage tends to vary a good bit from operating system to operating system, and you might see different behavior on Windows.
So it’s not just the per-page memory usage that’s being a problem in terms of Firefox responsiveness…
As for your screenshot, I did ask for examples of pages where memory usage grows, right? That doesn’t seem to be it… Certainly if I load that page memory usage stays pretty constant while it’s loaded. ;)
-
Christopher,
I have the latest release, and haven’t had time to load the debugging version. I have found a pattern and website that will lock up firefox AND the desktop in Linux and on Windows.
The website is Scottrade and the behaviour is just to jump around looking at stocks and all, then BOOM it stops. If you click on another application (in linux), it will switch. However if you click on the browser window again, the entire desktop blocks for minutes (garbage collection?) and then will continue running. Just thought you might want to know. Kernel 2.6.19 – preemptive settings, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
I will post if I get the time and find the bug. I surf by tabs, always have 10-20 open for when I get time to read them. Never ran into this on any other site. Only Scottrade. Lots of javascript so I think its in there.
-T- -
I’ve seen this since FF 1.0, although it seems to have gotten worse, not better.
I can only use the browser for a day or two (depending on how heavy my usage is) before the CPU usage ramps up. Anything causes long pauses of 100% CPU usage, getting progressively worse. Restart, they go away for a day or two again. This happens with or without extensions.
Oddly enough, I see this on Linux but not on OS X (I don’t use Windows). Perhaps the allocator on OS X is just plain better? Worth investigating, at least.
-
Pingback from FireFox memory leaks | Rick Tech on November 24, 2007 at 1:17 pm
-
“As for why Gecko might be more appropriate for Mobile devices? If you look at all of the issues in the choice of technology that’s out there there’s one overriding fact – flat out more of the web works in Firefox and Gecko than in WebKit.”
While there may be some truth to this, I think the compatibility gap has shrunk to being pretty small indeed with the Safari 3 version of WebKit. I expect it will continue to shrink as WebKit market share continues to grow – there’s some degree of delayed reaction before sites notice that a browser’s market share is big enough to matter to them. I would also guess that specifically mobile-targeted content may already be more compatible with WebKit than Gecko.
Become a Friend of Gnome!
Watch as I Grow
interesting stuff
- On 1:1s :: dria.org March 10, 2010
- Streaming Media - Ogg, MPEG LA, and Submarine Patents March 9, 2010
- Opera Core Concerns - Everything you need to know about HTML5 video and audio March 4, 2010
- PdaNet -- USB Tether/Bluetooth DUN for Android March 2, 2010
- html5media - Project Hosting on Google Code March 1, 2010
56 comments
Comments feed for this article
Trackback link: http://www.0xdeadbeef.com/weblog/2007/11/memory-usage-in-firefox-and-gecko/trackback/