Firefox 3 Memory Usage
As the web and web browsers have matured, people have started expecting different things out of them. When we first released Firefox, few people were browsing with tabs or add-ons. I’ve written before about how web usage patterns have changed, so too have our strategies on how to effectively make use of system resources such as memory.
While Firefox 2 used less memory than it’s predecessor, Firefox 1.5, we intentionally restricted the number of changes to the Gecko platform (Gecko 1.8.1 was only slightly different than Gecko 1. 
on which Firefox was built. However, while the majority of people were working on Firefox 2 / Gecko 1.8.1, others of us were already ripping into the platform that Firefox 3 was to be built on: Gecko 1.9.
We’ve made more significant changes to the platform than I can count, including many to reduce our memory footprint. The result has been dramatic, and you can see for yourself by getting a copy of the recently released Firefox 3 Beta 4.
Here’s What We’ve Done:
Reduced Memory fragmentation
As I’ve written about before, long running applications such as ours can wind up wasting a lot of space due to memory fragmentation. This can occur as a result of mixing lots of various sized allocations and can leave a lot of small holes in memory that are hard to reuse.
One of the things we did to help was to minimize the number of total allocations we did, to avoid unnecessarily churning memory. We’ve managed to reduce allocations in almost all areas of our code base. The graph below shows the number of allocations we do during startup. The graph below shows we were able to get rid of over 1/3 of them! Olli Pettay, Jonas Sicking, Johnny Stenback, and Dan Witte all made a big difference here.
I carefully studied the fragmentation effects of various allocators and concluded that jemalloc gave us the smallest amount of fragmentation after running for a long period of time. I’ve worked closely with the jemalloc author, Jason Evans, to port and tune jemalloc for our platforms. It was a huge effort resulting in Jason doubling the number of lines of code in jemalloc over a 2 month period, but the results paid off. As of beta 4 we now use jemalloc on both Windows and Linux. Our automated tests on Windows Vista showed a 22% drop in memory usage when we turned jemalloc on.
Fixed cycles with the Cycle collector
Some leaks are harder to fix than others. One of the most difficult ones is where two objects have references to each other, holding each other alive. This is called a cycle, and cycles are bad. In previous versions, we’ve used very complex and annoying code to manually break cycles at the right times, but getting the code right and maintaining it always proved to be difficult. For Gecko 1.9, we’ve implemented an automated cycle collector that can recognize cycles in the in-memory object graph and break them automatically. This is great for our code as we can get rid of lots of complexity. It is especially significant for extensions, which can often inadvertently introduce cycles without knowing it because they have access to all of Firefox’s internals. It isn’t reasonable to expect all those authors to write code to manually break the cycles themselves.
Basically, the cycle collector means there are whole classes of leak that we can easily avoid in both our code and in extensions, and that’s good for everyone. You can thank Graydon Hoare, Peter Van der Beken and David Baron for their amazing hard work on this.
Tuned our caches
Firefox uses various in-memory caches to keep performance up including a memory cache for images, a back/forward cache to speed up back and forward navigation, a font cache to improve text rendering speed, and others. We’ve taken a look at how much they cache and how long they cache it for. In many cases we’ve added expiration policies to our caches which give performance benefits in the most important cases, but don’t eat up memory forever.
We now expire cached documents in the back/forward cache after 30 minutes since you likely won’t be going back to them anytime soon. We have timer based font caches as well as caches of computed text metrics that are very short lived.
We also throw away our uncompressed image data as I describe below…
Adjusted how we store image data
Another big change we’ve made in Firefox 3 is improving how we keep image data around.
Images on the web come in a compressed format (GIF, JPEG, PNG, etc). When we load images we uncompress them and keep the full uncompressed image in memory. In Firefox 2 we would keep these around even if the image is just sitting around on a tab that you haven’t looked at in hours. In Firefox 3, thanks to some work by Federico Mena-Quintero (of GNOME fame), we now throw away the uncompressed data after it hasn’t been used for a short while. Not only does this affect images that are on pages in background tabs but also ones that are in the memory cache that might not be attached to a document. This results in pretty dramatic memory reduction for images that aren’t on the page you’re actively looking at. If you have a 100KB JPEG image which uncompress to several megabytes, you won’t be charged with the uncompressed size when you’re not viewing it.
Another fantastic change from Alfred Kayser changed the way we store animated GIFs so that they take up a lot less memory. We now store the animated frames as 8bit data along with a palette rather than storing them as 32 bits per pixel. This savings can be huge for large animations. One extreme example from the bug showed us drop from using 368MB down to 108MB — savings of 260MB!
Hunted down leaks
Most leaks are a pain in the ass to find and fix in any complex piece of software. There are small leaks, big leaks, and in-between leaks. If you leak a small piece of text once an hour you probably won’t notice. If you leak a large image every time you move the cursor, you’ve got a big problem. Both are important to fix, because even the little ones add up. Some leaks are only leaks until you leave a page, so they don’t show up with conventional leak-finding tools, but they make a difference if you have a page opened all day long like GMail.
Ben Turner has gotten pretty good at Leak Hunt.
We’ve fixed many leaks, ranging from small DOM objects that get leaked on GMail until you leave the site to entire windows that were leaked holding on to everything inside of them when you closed them.
Overall, we’ve been able to close over 400 leak bugs so far, most of which are very uncommon, but can still occur. We’ve greatly improved our tools for detecting leaks. Carsten Book, in particular, has done an amazing job at finding and reporting leaks.
Measuring Memory Use
As I’ve learned the hard way, accurately measuring memory usage is hard.
This part gets a bit technical, feel free to skip over. The short summary is Windows Vista (Commit Size) and Linux (RSS) provide pretty accurate memory measurement numbers while Windows XP and MacOS X do not.
If you’re running Windows Vista and take a look at Commit Size in task manager, you should get some pretty accurate memory numbers. If you’re looking at Memory Usage under Windows XP, your numbers aren’t going to be so great. The reason: Microsoft changed the meaning of “private bytes” between XP and Vista (for the better). On XP the number is the amount of virtual memory you’re application has reserved for use. For performance reasons you often want to reserve more memory than you actually use. The application can tell the operating system that it isn’t going to use parts of the reserved space and to not back the virtual space with physical space. On Vista, Private Bytes is the commit size, which only counts the memory the application has actually said it is actively using. Since virtual memory size has to be greater than or equal to your commit size, XP memory numbers will always appear bigger than Vista ones, even though the application is using the same amount of memory.
On Mac, If you look at Activity Monitor it will look like we’re using more memory than we actually are. Mac OS X has a similar, but different, problem to Windows XP. After extensive testing and confirmation from Apple employees we realized that there was no way for an allocator to give unused pages of memory back while keeping the address range reserved.. (You can unmap them and remap them, but that causes some race conditions and isn’t as performant.) There are APIs that claim to do it (both madvise() and msync()) but they don’t actually do anything. It does appear that pages mapped in that haven’t been written to won’t be accounted for in memory stats, but you’ve written to them they’re going to show as taking up space until you unmap them. Since allocators will reuse space, you generally won’t have that many pages mapped in that haven’t been written to. Our application can and will reuse the free pages, so you should see Firefox hit a peak number and generally not grow a lot higher than that.
Linux seems to do a pretty good job of reporting memory usage. It supports madvise(), allowing us to tell Linux about pages we don’t need, and so its resident set size numbers are fairly accurate. You can use ps or top to measure RSS.
Ways to test
There are many ways to measure memory usage in a browser. Open up 10 tabs with your favorite websites in them and see how much memory the browser is using. Close all but the last tab and load about:blank or Google. Measure again. Another simple test is simply loading Zimbra, Google Reader and Zoho each in their own tab and logging in. We’ve learned that users do so many things with the browser it is nearly impossible to construct a single test to measure memory usage.
We wanted more of a stress test — One that was more reproducible than loading random sites from the web. We took our Standalone Talos framework and Mike Schroepfer modified it to cycle pages through a set of windows while opening and closing them to try and approximate people running for a long period of time. Talos makes it pretty straightforward to get this up and running, and is great for measuring things like memory usage and layout speed. This works great for Firefox and allows measuring performance and other metrics, but the page cycling code doesn’t work with other browsers.
Since we wanted to test cross-browser, we modified the tests to run cross-browser and we wired up some of our talos code that uses the Windows Performance Counters to measure Private Bytes (commit size on Vista).
For the results below we loaded 29 different web pages through 30 windows over 11 cycles (319 total page loads), always opening a new window for each page load (closing the oldest window alive once we hit 30 windows). At the end we close all the windows but one and let the browser sit for a few minutes so see if they will reclaim memory, clear short-term caches, etc. There is a 3 second delay between page loads to try and get all the browsers to take the same amount of time. We used the proxy server that is part of Standalone Talos to make sure we were serving up the same content. We had to disable popup blocking to allow the test window to open the 30 windows for running the test. You can get the simple webpage test here and the python script to monitor memory usage here. These things are built on top of the standalone talos framework so you’ll need to drop the python script in with talos to get good results. Mad props to Mike Schroepfer for getting this all working.
Results
Looking at the graph:
- All browsers increase in memory use slightly over time, but the Firefox 3 slope is closer to 0.
- The _peak_ of Firefox 3 is lower than the terminal size of Firefox 2!
- The terminal state of Firefox 3 is nearly 140MB smaller than Firefox 2. 60% less memory!
- IE7 doesn’t appear to give any memory back, even after all the windows are closed!
- Firefox 3 ends up about 400mb smaller than IE7 at the end of the test!
This is just one test that I feel shows the great progress that has been made. We’ll continue working on adding additional tests that can measure more of the ways that users use their browser.
Conclusion
Our work has paid off.
We’re significantly smaller than previous versions of Firefox and other browsers.
You can keep the browser open for much longer using much less memory.
Extensions are much less likely to cause leaks.
We’ve got automated tools in place to detect leaks that might result from new code. We’re always monitoring and testing to make sure we’re moving in the right direction.
All of this has been done while dramatically improving performance.
Thanks
Many people have worked on this but I’d like to specifically thank: David Baron, Carsten Book, Peter Van der Beken, Igor Bukanov, Brendan Eich, Jason Evans, Alfred Kayser, Federico Mena-Quintero, Robert O’Callahan, Olli Pettay, Mike Schroepfer, Mike Shaver, Jonas Sicking, Johnny Stenback, Ben Turner, Vladimir Vukicevic, Dan Witte, Boris Zbarsky, and everyone else I’m forgetting who has worked on this. Everyone really pulled together to make this happen.
Tags: beta 4, bloat, caching, cycle collector, firefox, IE7, jemalloc, leaks, memory fragmentation, memory usage, Mozilla, testing
March 11, 2008 at 11:03 pm
Nice writeup on the memory usage in general and of the work you and your colleagues have done and what you have achieved.
Thank you,
Tyler out!
March 11, 2008 at 11:42 pm
[...] som Firefox 3 beta4 har fått en bra behandling mot [...]
March 11, 2008 at 11:53 pm
I have worked on more than 100 bugs related to memory allocation, particularly in image decoding, jarfile reading, caches, but in other places as well:
Furthermore I have a number of patches waiting for review addressing memory allocation issues that could improve the numbers for FF3 even more, but it seems that lately there is less attention to this: http://tinyurl.com/2qemda
March 11, 2008 at 11:53 pm
Is about:memory going to be implemented for Firefox 3, or was it bumped for about:robots ?
In a nice bit of near-crunch goalpost moving, the bug got fixed by changing what it was for:
https://bugzilla.mozilla.org/show_activity.cgi?id=392351>
Who: vladimir@pobox.com
When: 2008-03-05 16:39:08 PDT
What: Summary
Removed: Implement about:memory page
Added: implement about:memory framework core
March 11, 2008 at 11:58 pm
Firefox 3 is truly amazing in terms of memory usage. I think that the other browser are soon going to follow the good example set by Firefox.
Thanks for the great work put into the very important release!
I think this once and for all ends the “my Firefox is using too much memory” discussion.
This also leads the way to make Firefox available on low memory devices like mobile phones, etc
March 12, 2008 at 12:00 am
[...] pavlov.net has a good writeup about the memory usage in firefox 3, covering the effort that went into it as well as evaluation methods and results. It’s an easy and interesting read, with pictures! With 8 tabs of fairly large pages open right now, and the browser open for a day or two, firefox is now using 175MB on my computer. [...]
March 12, 2008 at 12:19 am
[...] stumbled upon Firefox 3 Memory Usage via Twitter tonight. The post, from Mozilla software engineer Pavlov, goes into great detail [...]
March 12, 2008 at 12:27 am
Mozilla releases Firefox 3 Beta 4. The Robots are getting faster!
A couple of days ago (2008-03-10), Mozilla officially released Firefox 3 Beta 4. Once again the latest Beta release has managed to improve over its predecessor. Beta 4 remains very! stable, further tweaks under the hood and more memory leaks
March 12, 2008 at 1:07 am
This is really awesome. But there is one thing I don’t understand. If you start Firefox with an empty page it uses about 30MB but if you have opened 100 tabs and close them Firefox will use 80 to 130MB. What is that extra 50MB used for?
March 12, 2008 at 1:24 am
[...] Interessante approfondimento sul consumo di memoria. Si pu discutere sull’interfaccia per Windows, ma quella per Mac indubbiamente 20 volte meglio di quella del 2. Altrimenti prova/provate questi.. [...]
March 12, 2008 at 1:32 am
I’d like to thank you Stuart. I firmly believe the last thing that was really hampering the ‘fox’s potential was perf/memory. It seems some very substantial steps have been taken to correct what was a very drastic problem.
I hope now that progress will continue beyond the point where perf/memory is now as good as other browsers and in some cases better. Ideally I think that a huge ’selling point’ for Firefox, that could push it up to 50% share in some sectors, would be to be able to brag about how much it outperforms other browsers. Do you think Mozilla will rest on the current achievements or go even further and make perf/memory an unquestionable advantage for the ‘fox?
C O N G R A T U L A T I O N S
on the progress thus far!
March 12, 2008 at 1:35 am
@Ferdinand: Based on what the article said, you can probably assume that it is caching the pages for up to 30m in case you are going to visit them again in your history (re-opening old tabs etc). Considering how many images are out there, even if they now compressed 100 tabs should probably take up between 50mb or more.
March 12, 2008 at 2:15 am
It sounds as if firefox’s past memory problems will in the end turn out to be a good thing. It forced you to make tools and a system for memory control that will make it surpass other browsers memory footprint in the future.
March 12, 2008 at 2:32 am
I started out on phoenix way back when; in the intervening time, I’ve been over to opera a few times (crashes; sorry opera fans) and limited trials of kazahakase but I always end up back in firefox.
I actually installed the restart firefox extension to try to alleviate memory consumption, so this blog post is really good news to me. Call me a Luddite, but I’d like to be able to work comfortably in my 512 megabytes of RAM.
One interesting and entirely tangential observation however, is that X memory usage also creeps up gradually, implying memory leaks. Qualitative observation indicates that this happens at an accelerated rate with heavy firefox usage, and I just wonder if that is something to be addressed on the firefox side or the X.org side.
March 12, 2008 at 2:36 am
Ferdinand, different caches, pages converted to DOM, unpacked images, ….
March 12, 2008 at 2:44 am
And.. how would the latest opera beta compare?
March 12, 2008 at 2:55 am
Thank you!
March 12, 2008 at 3:16 am
Where are Opera tests? You should include them to give full picture.
March 12, 2008 at 3:18 am
Great article showing all the progress done and all the good work associated.
There is still some gain left for Firefox3 (bug 399925 about gif decoder discarding data…).
I hope about:memory will be available also for Fx 3.
What I would like for the future is the ability to have plugins run into separate process, info about memory used by plugins, ability to manually unload a plugin, automatic unloading when not used.
I hope there will also some mean to reduce/control cpu usage (like stopping animations when content is not visible) and to have info about which page is hogging cpu, …
March 12, 2008 at 3:52 am
Excellent job, it was becoming a critical problem with FF. I am eager to test FF3.
But Opera is still the best in terms of memory and page loading time. (Opera is less extensible than FF, but I don’t know if the two differences are linked).
When you’re talking performance, you should put Opera in your comparison.
(When you’re talking market share, it should be IE).
March 12, 2008 at 4:01 am
I use firefox2 at work and it eats up memory through the day, I have to close it a couple of times to getting running smoothly again. http://www.thevirusmustbestopped.com/
March 12, 2008 at 4:14 am
A difference of opinion
On Pavlov.net talking about some improvements in memory handling on Firefox 3:
It isn’t reasonable to expect all those authors to write code to manually break the cycles themselves.
This reminded me immediately of an MSDN article that took a decidedl…
March 12, 2008 at 4:46 am
Thumbs up
March 12, 2008 at 5:16 am
[...] Memory usage of Firefox 3 (beta 4) is found to be lower than FF2 and much lower than IE7, this study at Pavlov.net shows. I don’t know why anyone is still using [...]
March 12, 2008 at 5:20 am
[...] [view original post] [source: Delicious] Previously - [JS]スタイルシートを機能拡張するスクリプト -MoreCSS Next - [...]
March 12, 2008 at 5:42 am
Thanks a lot to all concerned for their great work! I still haven’t tested the last beta on linux but on winXP, it’s really amazing! i also enjoyed the explanations.
March 12, 2008 at 5:50 am
Just out of curiosity. Could you please also include opera in your comparison? Reduced memory usage definitely is good news. Thanks.
March 12, 2008 at 6:04 am
Second paragraph has a typo: “While Firefox 2 used less memory than it’s predecessor” — “it’s” should be “its”.
March 12, 2008 at 6:09 am
[...] site “” post, browser [...]
March 12, 2008 at 6:43 am
Hi Team,
I just wanted to thank all of you for the work you’ve done on this. It sounds fantastic. I’m an avid FF user, and reading this article and helping me understand the scale of what you work on has convinced me to donate to Mozilla for the first time. You all clearly deserve to be rewarded for your work. I can only hope the improvements keep coming, because this sounded fantastic!
Sam
March 12, 2008 at 6:54 am
Just out of interest, how does it compare to the only other serious competitor on Windows, namely Opera? Could someone re-run the test with an Opera line in there. If Opera’s worse, congrats to FF team. If it’s better, it’s a target to beat.
March 12, 2008 at 7:02 am
Wow. That all sounds great. But alas I am using v4 Beta 3 on my XP work laptop (and I suspect most business users are and will be using XP for some time). So in the end, while the graphs look great, and it sure sounds like you’ve done a lot of hard work, doesn’t it really only matter what the perceived result is to the end user?
I like the new version. But honestly it doesn’t seem all that different to me. It is currently using 180mb of RAM with 4 tabs open. Somehow, that actually seems worse than v3. No doubt XP is the evil culprit, but is there nothing that can be done to appease the vast number of business users until Vista (or Linux) becomes the biz standard?
March 12, 2008 at 7:15 am
Very cool, I’m eager to see FF3 go live!
March 12, 2008 at 7:17 am
Ferdinand, I don’t know a complete answer to your question, but to start with, notice that you can “unclose” those closed tabs in Firefox so it’s still tracking that data for a while just in case you made a mistake and want it back. Further, you now have plenty of images, stylesheets and other stuff cached in memory, in case you revisit those tabs soon.
So when you close all those tabs you’re not really in the same state that you started in, it just appears that way on the surface. The changes in Firefox 3 should mean that a browser left idle on your desktop while you get on with some real work will be giving back more of the RAM, making the whole experience more acceptable.
March 12, 2008 at 7:19 am
Honest question: Why didn’t you include Opera in the graph above? The test runs perfectly well in it.
March 12, 2008 at 7:24 am
Although I cannot judge the result of efforts from a strictly technical point of view, it seems you guys took a big setp toward definitely improving FireFox as whole and of course I really appreciate your efforts, duely paid off with your partnership with Google. Now a question: So the big next step will be to improve the abominable present-state bookmark manager, right? Did you know: the user may have to wait several minutes until 50, 100 or more bookmarks get deleted when he hits the DEL key on a bookmark folder holding that much of addresses! While this improvement does not come out into being, I am afraid I’ll stick to Opera.
Regards.
March 12, 2008 at 7:28 am
You mention RSS for Firefox itself, but do you calculate the RAM consumed by the X server as well?
March 12, 2008 at 7:33 am
Memory handling stuff improvement? Sorry, I cannot notice a single bit! Firefox is taking up (right now) almost 50 MB of my memory, with just 5 addons installed!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
March 12, 2008 at 7:42 am
Congrats! This is very good news indeed!
BTW, how does Firefox 3 memory usage compare to Opera 9.25 on Windows XP and Linux?
March 12, 2008 at 7:49 am
Hey Pav,
Is there a reason why you have not included IE8 Beta 1 and Safari in your measurements?
March 12, 2008 at 8:20 am
whoa, lots of comments to reply to.
Tristan: We attempted to run IE8 through the test but had problems with it showing broken images, giving error pages and freezing up while running the test. We had similar problems with Safari. It seemed to follow the IE7 line pretty closely up to about 350MB until it crashes very early on. I haven’t tried Opera, but people should give it a shot.
March 12, 2008 at 8:23 am
Fx: Haven’t tested with 9.25, but with latest weekly from http://my.opera.com/desktopteam/blog/ under Windows XPSP2.
Results: Peak at 180 MB; after closing all windows, back to 120 MB. So it’s a bit better in normal use, but also clings more to stuff it has cached.
March 12, 2008 at 8:35 am
The graph is great! I’d like a clarification though: How does the terminal state compare to the initial pre-test state (one window, freshly opened) for each browser?
(And I’d like to see other browsers listed as well, if that’s possible.)
Typo note: “amount of virtual memory you’re application”
March 12, 2008 at 9:02 am
[...] big changes are coming in Firefox 3. Mozilla’s Pavlov has written a detailed post on Firefox 3 Memory Usage, describing the different categories of memory improvements that have been made in the [...]
March 12, 2008 at 9:17 am
Since folks asked I ran the latest Opera 9.5b in the exact same environment. It peaks around 240MB and doesn’t free up any memory at the end (so ends at 240MB). 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. I sent stuart the raw data if he wants to update the graph.
March 12, 2008 at 9:52 am
Beautiful! Your hard work & openness is very much appreciated. Looking forward to FF3!
March 12, 2008 at 9:54 am
[...] in improving both our top line size but also how predictable our memory usage is. Stuart has an absolutely fantastic post that covers all of the work that we’ve done in this release cycle to the browser. (And it has [...]
March 12, 2008 at 9:59 am
Why K-Meleon CCFME 0.08b1 is using about 4 times memory less than FF2? Usually 50 MB vs. 200 MB…
March 12, 2008 at 10:01 am
Firefox 3 kicks ass!!!!!!!!!
March 12, 2008 at 10:04 am
you guys rock. will download and install beta 3 right away.
March 12, 2008 at 10:07 am
You mentioned that FF3 memory usage on Windows is down 20%. What is that figure on Linux compared to GNU libc’s malloc?
March 12, 2008 at 10:13 am
rob: we saw about a 7% drop on Linux when we turned jemalloc on there iirc.
March 12, 2008 at 10:19 am
[...] Significantly improved memory management which means that it won’t hang as often when it’s been open for long periods of time. (Who closes their browser anymore?) [...]
March 12, 2008 at 10:19 am
compare it with IE8 & Opera too…
March 12, 2008 at 10:29 am
Great article Pav!!! No wonder you’re not around on irc anymore
#wl sends its love.
March 12, 2008 at 10:31 am
Cool!
NItpick: “While Firefox 2 used less memory than it’s predecessor…” that should be “its” — “it’s” means only “it is.”
March 12, 2008 at 10:37 am
Thanks for good work. The summary sounds impressive.
I’m looking forward to give it a try in my testing environment. btw. ie8 beta didn’t pass yet
March 12, 2008 at 10:51 am
That sounds great. Unfortunately, I gave up on Firefox when 2.0 came out and kept eating up all of my memory from memory leaks.
I have since been using Opera and have been delighted.
At this point I would need a compelling reason to switch back to Firefox, as feature-wise, Opera meets or exceeds Firefox in every area that matters to me.
March 12, 2008 at 10:57 am
Sounds great cant wait!
March 12, 2008 at 11:01 am
Thanks so much for all your hard work!
March 12, 2008 at 11:11 am
Hmm, just tried to do a comparative test with Firefox 3 Beta 4. Funnily the main window of your test informed me that it had blocked 110 popups. This despite the popup blocker being off and your site being specifically on the allow list.
How do i disable this so i can get the real ram usage numbers?
Does the same thing happen when you run your test?
March 12, 2008 at 11:12 am
Nice work! It’s good to see improvements in this area.
March 12, 2008 at 11:12 am
Nice. I’m looking forward to the finished Firefox 3.
Here’s a test you might want to use for future comparisons. Have a 200k-300k page that includes lots of tabular information with minimal javascript that uses a meta refresh to reload itself every 5 minutes. For Firefox 2 on Linux (Ubuntu 7.10), this causes Firefox 2 to increase its memory footprint by a megabyte or two on every reload. After a few hours, RSS is between 400-500 megs. If left running overnight, RSS is over a gig. By that point, Firefox 2 needs to be forcibly quit as it takes longer than 10 minutes to quit on its own.
I normally run with Web Developer, Firebug, NoScript, and a few other plugins, but this behaviour is consistent when all plugins are disabled along with javascript.
If Firefox 3 eliminates this particular instance of memory growth, then I’d consider switching to using the beta version right away.
March 12, 2008 at 11:20 am
[...] explains about Firefox 3 memory usage and how the browser effectively managed [...]
March 12, 2008 at 11:25 am
I have tried out the Beta 4 and I must say I am very impressed. I run a somewhat obsolete computer and would under no circumstances update to IE7 because it was WAY too slow on my computer.
I have been looking for some time for something as fast as IE6 without a bunch of bells and whistles and I must say that I am extremely happy with the Beta 4. The other releases ran very slowly on my machine as well which is why I didn’t move to Firefox sooner. The Beta 4 however is a whole new thing. It has the simplicity and speed that I was looking for.
I have previously tried Opera (failed horribly on my machine due to it’s poor response time), Maxthon2 (OK but too many bells and whistles), Browzar, Beta release of Safari for Windows, and numerous other “Lightweight” browsers and none can compare with FF 3 B 4. The others were either: not user friendly, too complicated, wouldn’t work at all, or were test releases which had a lot of bugs.
I am definitely considering this my new browser over IE6 in terms of simplicity and speed.
Thanks so much for the amazing progress in better web browsing for all!
March 12, 2008 at 11:35 am
Really great article, thanks!
FF2 was good, but I use lots of tabs and keep the browser open for hours (or days). So I started restarting FF when memory got too high or it got sluggish.
When the betas for FF3 started coming out, I was blown away. I’ve been using the nightly builds now for a while because of the _absolutely outstanding_ work that’s been done on memory and performance (and other improvements which is good too).
Kudos to everyone working on FF3.
March 12, 2008 at 11:43 am
Congratulations. I look forward to Firefox 3.
March 12, 2008 at 11:43 am
What about OS X? I see none of these reductions in memory on OS X. Yet when I run firefox in windows, these reductions are very clear.
March 12, 2008 at 11:44 am
Manual trackback:
http://standblog.org/blog/post/2008/03/12/Follow-up-on-Pavlovs-post-on-memory-usage
March 12, 2008 at 11:46 am
[...] popular demand, Mike Shroepfer put Opera 9.5beta under the same test, and found it peaks at 240MB (compared to FF3’s 220MB) and releases down to 220 MB (pretty [...]
March 12, 2008 at 11:49 am
Great Essay!
I’m really impressed all around, at the creativity and hard work. I just love what the open source community is capable of.
Thanks Guys
March 12, 2008 at 11:59 am
Just a small Thank You for the well written article, and a great big THANK YOU to all who contributed to the hard work that has been done in order to get to the point where there was an article to be written.
Every contribution is really appreciated.
March 12, 2008 at 12:06 pm
Nice work gentlemen! B4 is much, much more usable on a 1.3GHz PowerBook G4 as a result.
-saari
March 12, 2008 at 12:11 pm
What youve made strides in memory wise, has skirted over to the processor, so now you have a processor whore instead of a memory hog.
i dont know what it is, but this is horrible. i have to reduce the number of tabs i have open to even use another application on my system.
cutting the memory usage by 60% but increasing the cpu usage by 30+% is no gain in my opinion.
optimize FF for power users, not casual users and its easier to satisfy the casual user, its still a long ways off.
loading 100+ tabs at once crashes the program, it would be nice if it could handle a significant load, instead of expecting to load 5 or so pages.
March 12, 2008 at 12:19 pm
Excellent write up. I am glad that Mozilla have addressed this issue, as memory usage is just about the only complaint I have about Firefox.
March 12, 2008 at 12:32 pm
[...] 12, 2008 in Firefox The Firefox 3 Memory Usage No Comments Leave a Commenttrackback addressThere was an error with your comment, please try [...]
March 12, 2008 at 12:39 pm
[...] View: Firefox 3 Memory Usage [...]
March 12, 2008 at 12:40 pm
[...] [view original post] [source: Delicious] Previously - Write a well structured CSS file without becoming crazy Next - [...]
March 12, 2008 at 12:41 pm
That last graph surprised the heck out of me, I figured with IE7 that Microsoft would be much better than that.
And you’re right, this information does show that your work has paid off, I have been using the nightly builds and now the beta builds of firefox 3 and I love how its progressed.
Thanks for all your hard work, it is beyond appreciated.
March 12, 2008 at 12:46 pm
[...] 3, Mozilla, Opera Browser, web browser — Lorenzo E. Danielsson @ 20:46 Just came across this which confirmed the feeling I’ve had for the last few days: Firefox 3 is fast and memory [...]
March 12, 2008 at 12:53 pm
Congrats, it nice to see good work being done to make firefox even better.
March 12, 2008 at 12:56 pm
[...] http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ [...]
March 12, 2008 at 12:57 pm
I once blamed Firefox for my memory problems when I noticed streaming video would make my system almost unusable. After weeks of trying all sorts of solutions all I had to end up doing was clean the inside of my computer. After I did that, BOOM, everything was back to normal.
I’m not suggesting Firefox doesn’t have memory issues, but I would bet there are many people who blame Firefox when there is a deeper problem.
March 12, 2008 at 1:01 pm
Updated graph with Opera 9.5 and Safari can be found here:
http://www.flickr.com/photos/stuartp/2328802961/
March 12, 2008 at 1:03 pm
Firefox used to have a command that writes all the memory out of ram to the desktop then writes it all back once the browser is opened. Will 3 have that? I think it was config.trim.onminimize for 1.5
For Linux users who never shit down their computers leaving 5gb worth of Firefox browsers up is not out of the ordinary. It would be perfectly fine if we could just write it to the hard drive when it is minimized.
March 12, 2008 at 1:04 pm
That’s some great graphs. I’m going to upgrade to Firefox 3.0 as soon as possible. Can’t wait for the final version
March 12, 2008 at 1:10 pm
[...] Firefox 3 Memory Usage - Pavlov [...]
March 12, 2008 at 1:10 pm
Bookmarks. Why the complexity of using a database to replace the simplicity of an html to hold bookmarks? My bookmarks file is bloated at 1MB but storing the whole thing in RAM would be easy. Like GuesstWatt I was surprised when I deleted a bookmark folder and it took so long. After a while I though Firefox had locked up. I toggled off elsewhere and waited a while. Later it had completed the deletion. A simple html bookmark file was one way Firefox was more user friendly than IE. That advantage was erased.
March 12, 2008 at 1:11 pm
Great work, guys, thanks a lot!!! Good to see that my beloved web browser is becoming better and better with every next edition
March 12, 2008 at 1:19 pm
[...] around cache management and image handling should result in a leaner and meaner browser. Click here to read [...]
March 12, 2008 at 1:32 pm
Opera releases as well, it simply takes a while longer. Leave it running for the same time as the others.
Also, still waiting on an answer on how to actually deactivate FF’s popup blocker.
March 12, 2008 at 1:32 pm
Excellent. Firefox is by far the best browser I’ve used-even with the memory annoyances. I still run into occasional problems with pages that are poorly written, but that is much less common. I’m looking forward to being able to delete IE.
http://aphilosopher.wordpress.com
March 12, 2008 at 1:55 pm
How many times did you run this test, before getting this one result you were looking for?
March 12, 2008 at 2:09 pm
Great thanx.
You’re making a good job there.
Keep up.
March 12, 2008 at 2:10 pm
[...] http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ Read More Post a Comment [...]
March 12, 2008 at 2:30 pm
Pavlov, thanks for all the insight into FF3! Can you try running the script w/ webkit nightly? I’d be interested to see a completed test for Safari
March 12, 2008 at 2:57 pm
I think this is a great fix for Firefox. It really hurts in version 2 that you have to restart the browser when you start hitting high memory usage. Thanks for all your hard work on Firefox. It is a truly amazing piece of software.
March 12, 2008 at 2:59 pm
@rambutan
You can still export your bookmarks to an .html file if you want.
March 12, 2008 at 3:36 pm
I have been running firefox nightlies for stretches of five days with unreasonable number of tabs (~100), a few extensions, the memory is stable and the browser responsive. So worth it.
March 12, 2008 at 3:39 pm
Looks great. Would be nice to see a comparison to Opera 2.6 though.
March 12, 2008 at 3:46 pm
This is good news. But it still pisses me off no end that for all these years the Firefox devs have done absolutely *nothing* other than deny that there were any memory problems. Quite frankly its about friggin’ time they came clean about it rather than spouting the organisation line. Meanwhile i’ll stick with Opera until FFX3 final is released and has proved itself.
March 12, 2008 at 3:53 pm
[...] Interessante approfondimento sul consumo di memoria. Si pu discutere sul tema per Windows, ma quello per Mac indubbiamente 20 volte meglio di quella del 2. Altrimenti prova/provate questi.. O non ti piace la barra degli indirizzi nuova? Dopo un po’ che la si usa molto comoda, per i siti pi visitati basta scrivere la prima lettera e il primo risultato quello cercato. Ultima modifica di Namuris : Ieri alle ore 10.36.40. [...]
March 12, 2008 at 4:08 pm
[...] hace referencia al blog de un ingeniero de Mozilla, Stuart Parmenter, donde explica con detalle el trabajo realizado para minimizar el consumo de [...]
March 12, 2008 at 4:27 pm
@Moses
Please link to one of these denials, go on I’ll wait.
March 12, 2008 at 4:46 pm
[...] interesante sobre FF3 Para el q le interese, aca hay un articulo de uno de los programadores de FF3 sobre los problemas de leaks de memoria q tenia [...]
March 12, 2008 at 5:22 pm
Kudos on a fantastic report. Can’t wait for the final release. Long live FF!
March 12, 2008 at 5:35 pm
Mithaldu: I’ll see if we can rerun Opera and let it sit for longer. Also, you want to set dom.popup_maximum to some very large number to fully disable popup blocking.
March 12, 2008 at 5:39 pm
Hope your programing skills are better than your grammatical skills (it’s its not it’s).
March 12, 2008 at 5:46 pm
Moses, care to point me to URLs that support your claim that _Firefox_developers_ have done nothing other than deny memory problems? If you’re talking about Ben’s post* from a couple of years ago, (describing an intentional increase in Firefox’s memory use,) I’d start off by saying that was one developer and it was two years ago and it was mostly taken out of context. I’d encourage you to re-read it and note that he starts off by saying that yes there are indeed memory leaks and that we strive to fix them.
I will confess that a lot of people did respond to the shouts of “Fix the memory leak” saying something along the lines of “improving Firefox’s memory usage isn’t a matter of ‘fixing a leak’” and if you read Stuart’s post here, you’ll see that response was actually correct.
If you’re following closely, you’ll have also noticed that Firefox 1.5 and Firefox 2 were both shipped off of an older platform, Gecko 1.8, while for the last 2.5 years the people working on that platform (where much of this memory work took place) have been focused on Gecko 1.9, the new basis for Firefox 3.
Much of that work was happening during the time you claim that Firefox devs were doing nothing but denying a problem. That work couldn’t be included in Firefox 1.5.x or 2.0.x because it would have required major changes to Gecko that weren’t acceptable on the stable 1.8 branch. Now you’re seeing FIrefox 3 on the 1.9 branch and the fruits of much of that work.
* http://weblogs.mozillazine.org/ben/archives/009749.html
- A
March 12, 2008 at 6:00 pm
[...] put up a great post today describing the results of our intensive focus on memory use in Firefox 3 (and followed up, [...]
March 12, 2008 at 6:13 pm
I’ve found a big problem with the last nightly build and beta4 :
on my windows XP
-go to this digg page :
http://digg.com/settolerance?csorttype=c-all&return=/tech_news/Digg_This:_09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0&storyid=1901261
-wait for the 2.000 comments to load
-close the tab and watch the memory goes to 300mb or 500mb, the proc goes to 100% during 5sec, the disk to click and the browser to block
March 12, 2008 at 6:26 pm
Great report and the memory usage graph is very interesting. Just curious, do you have any data for IE6 in this comparison?
March 12, 2008 at 7:01 pm
[...] guys have made this a big focus of Firefox 3 and the new beta 4 shows the improvements mentioned in this post by Pavlov, one of the developers. If you want to test beta 4 without blowing away or risking your [...]
March 12, 2008 at 7:13 pm
[...] Firefox 3 Memory Usage [...]
March 12, 2008 at 7:18 pm
[...] 2 and IE7 by far. This article goes in-depth to explain Firefox 3’s memory technology(s).read more | digg [...]
March 12, 2008 at 7:39 pm
“Extensions are much less likely to cause leaks.”
Finally.
We’d like more information here. Abstraction magic or an extra helping of pixie dust?
March 12, 2008 at 7:39 pm
Alright, thanks a lot for being willing to be exact and for the advice, will try first thing tomorrow.
March 12, 2008 at 7:50 pm
Such an excellent read-great job and canot wait!
March 12, 2008 at 7:52 pm
I always knew Firefox was better than IE, but since IE8 has come out can you guys rerun the test to compare all four, IE7, 8 and Firefox 2 and 3?
March 12, 2008 at 7:52 pm
Thank you for working on Firefox. Where’s the “buy this man a pint” button?
March 12, 2008 at 8:30 pm
Hey pavvy, I just found this post via reddit. Just saying… http://reddit.com/info/6brl6/comments/
March 12, 2008 at 9:17 pm
I appreciate what you are doing but the only solution you mentioned that addresses a root cause is releasing the uncompressed images. I would think most potential gain would come from simply being smarter about memory consumption in the first place, not trying to recover after you’ve pulled in huge mem.
March 12, 2008 at 9:23 pm
regarding the “Adjusted how we store image data” part…
I would rather have my RAM used rather than have more burden put onto my processor. I personally have 2GB’s of RAM which I rarely see more than 75% consumed. If RAM is only stored the uncompressed images when not viewed and I want to rapidly look thru images my processor is going to end up slowing down as a result of having to process the image uncompressing rather than having the RAM used and just loading the images up quickly.
RAM is so cheap people, stop complaining about running out of RAM and just fricken upgrade… processors aren’t always so easy or cheap to upgrade on the other hand!
March 12, 2008 at 10:01 pm
This is a great article. I really have hopes that it does help stop extensions from causing leaks.
What about poorly written scripts within pages? Does this version of the browser try and trap and stop scripts from being the source of the leaks? Hopefully something to limit extensions to the amount of RAM they can take and the amount of RAM any one tab could eat would be great in my oppnion.
March 12, 2008 at 10:08 pm
[...] about Firefox 3 from Pavlov Firefox 3 Memory Usage pavlov.net __________________ [...]
March 12, 2008 at 10:33 pm
wow, thanks for what you are doing guys. i agree with woody, though. can you guys make a comparative test between IE8 and Firefox 2 & 3?
thanks
March 12, 2008 at 10:36 pm
Thank you very much for the opportunity to test out Firefox 3 Beta 4! I’ve only just downloaded it, but it looks great so far. I’ll test it’s memory usage right away.
Cheers!
March 12, 2008 at 11:06 pm
[...] developer ‘Pavlov’ wrote up some extensive details on memory use in Firefox 3. I highly recommend that you check it [...]
March 12, 2008 at 11:51 pm
I am using FF3 Beta 4 and JavaScript and Flash Player are issues. At times these are not clickable nor workable. Memory leaks can also be due to ms because xp and vista are a lot of the originator of the problems when the browsers crashes. When FF2 was released, I find FF2 really had a great deal of issues including frequent crashes and I still could not figure out what to pinpoint on expect running on Windows did not help. I tried on other versions written in the same language as FF, Flock. Its a little bit different than FF2 as for the feel and the experience. Mostly I use Netscape, Seamokey and FF 3 Beta.
March 12, 2008 at 11:58 pm
Congratulations
March 13, 2008 at 1:02 am
I think the used memory when running firefox 3 beta 3 with so many tabs is decreased almost halved - compared to firefox 2.0.0.12 version.
March 13, 2008 at 2:02 am
Firefox 3 Memory Usage
What FF team do to improve memory usage on FF3…
March 13, 2008 at 2:26 am
Great work guys…
Keep it up!
March 13, 2008 at 2:27 am
been using beta 4 for a couple of days now on my work laptop. normally, after 24 hours of running with the 30-50 tabs i have open at any one time, the RAM usage is up to between 400-500mb. the same sites/tabs in ff3b4 is currently using 150mb. fantastic!
now, hows about a tool that tells us how much cpu/ram specific tabs/plugins/etc are using, so we can find out which sites are killing the performance of the browser?
March 13, 2008 at 3:04 am
I’ve tested default installations of Firefox 3 beta 4, Opera 9.5 beta build 9815 and IE8 beta on Win2003.
Firefox cannot be tested properly, because I couldn’t disable popup blocking.
Opera allocated 200-210Mb of private memory during the test and shrunk it to 165Mb in several minutes after the test.
IE allocated 270-280Mb of private memory during the test and shrunk it to 170Mb just after the test.
The test in IE took much more time and network bandwidth than in Opera. It seems that Opera keeps more data in cache than IE.
March 13, 2008 at 3:17 am
If you are having cpu issues, it is probably flash related. Try flashblock and see if it makes any difference.
Makes IE slow as hell too on occasion, and crash.
March 13, 2008 at 4:04 am
[...] Firefox‘un bir türlü tam olarak üstesinden gelemediği bellek kullanımı meselesi yakında yayınlanacak olan 3. sürümünde çözülecek gibi görünüyor. Bu konuya yoğunlaşanlardan biri olan Stuart, sorunu çözmek için yapılanları kişisel günlüğünde teker teker aktardı. [...]
March 13, 2008 at 4:30 am
@kualla: Not everyone really has the option to upgrade. What if you’re using FF on somebody elses computer, are you going to buy them new RAM? What if it’s your company’s computer, or your university’s? What if you’re on a notebook?
Besides, even lots of ram doesn’t really help. To fill 2GB ram with image data, it only requires you to display about 1000 1024×768 images at once - this might seem like a lot, but in the age of broadband internet it’s not that much (it requires only 20 open tabs with 50 images on each). And we’re talking about 1024×768, which is (by today’s standards) almost low-res.
(BTW as far as I know, it’s still possible to bring the browser and OS to it’s knees if you load too many images at once, before the timer kicks in and starts deallocating memory.)
March 13, 2008 at 4:39 am
Great work, guys! I’m a Firefox user and I’ve always prefered Firefox to IE or other browsers and now that I know this about memory, I’m even more happy. I’m a translator and I need to keep the browser opened for hours, to have several online dictionaries as well as information sources at hand, when I’m working. Usually, my computer tends to get slow after many hours of runningFirefox with like 10 tabs open, plus Open Office, plus Winamp and plus other stuff. If Firefox uses less memory, maybe I can put a bit less of stress in my dear computer friend and that would be just great.
Thanks for all the hard work you put and such a fine product and keep it up, please!
Best regards.
March 13, 2008 at 4:45 am
[...] Uma das maiores melhorias no FF 3 é justamente no melhor uso da memória. Num artigo publicado em http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ são apresentadas e explicadas as principais melhorias. Resumindo, foi diminuido a fragmentação [...]
March 13, 2008 at 4:47 am
Great article, great work and yeah great FF!!
All the IE-users really don’t know what they miss…
March 13, 2008 at 4:52 am
[...] veja também um post do blog de Pavlov, um desenvolvedor do Firefox, explicando (em inglês) algumas melhorias no consumo de memória do [...]
March 13, 2008 at 5:20 am
Wow! This is great! This would really help my slow PC run decently.
March 13, 2008 at 5:41 am
Good work guys!!!
March 13, 2008 at 5:47 am
[...] team Mozilla ci segnala un articolo tratto dal blog di Stuart ‘Pavlov’ Parmenter sul consumo di memoria dei browser e in particolare di [...]
March 13, 2008 at 5:59 am
I have previously tried Beta release of Opera Beta and Safari in Windows, but none can compare with Firefox3 Beta4.
March 13, 2008 at 6:00 am
On the first image ( http://pavlovdotnet.files.wordpress.com/2008/03/alloccount.png ) what is are the axis labels or UNITS being measured in?
The same goes for the other image/chart ( http://pavlovdotnet.files.wordpress.com/2008/03/ff3-ff2-ie7.png ) — what is the X axis UNITS? Milliseconds? Seconds?
I’m just curious. I’m very impressed with the results…I am an avid FireFox supporter. I just wanted some more information on the units being measured in for the graphs……
NOTE ABOUT IE7 Memory Usage:
This is also hard to compare to FireFox. How are you comparing this exactly…since it is apart of the actual Windows operating system, how is it’s memory utilization being compared?
Internet Explorer would obviously take up more memory all of the time since it is running pieces of the Operating System, specially if users are using applications inside of Windows that would take up its resources (such as Control Panel, My Computer, any type of exploring files — well, I think you see what I mean). Is there a way of accurately measuring these factors or taking out the “Windows” bloat factor of IE or was this done in any way?
March 13, 2008 at 6:09 am
[...] look at memory usage in Firefox 3 Firefox 3 is making a lot of progress and there is even some research going on in the field of memory usage. As the web and web browsers have matured, people have [...]
March 13, 2008 at 6:29 am
[...] Also check out Firefox 3 Beta 4 review and Firefox 3 Memory Usage. [...]
March 13, 2008 at 6:40 am
This is a really well written post, i am a fan of the fox and will continue to spread firefox!
http://ThunkDifferent.com
March 13, 2008 at 6:41 am
Well done!
And great article, nice to read and understandable.
March 13, 2008 at 6:57 am
Thumbs up, great work!
March 13, 2008 at 7:00 am
[...] Speicherverbrauch der aktuellen Beta soll auch weiter verbessert worden sein, wie der Entwickler Stuart “Pavlov” Parmenter in seinem Blog schreibt. Das würde mich freuen, denn der Speicherverbrauch war teilweise nicht so [...]
March 13, 2008 at 7:03 am
I am once again excited and energized about firefox!
March 13, 2008 at 7:19 am
the latest beta is not behaving so well for me, climbing up to 1.2 Gigabytes at times! with around 25tabs open.
Not sure what triggers this climb, but the proc. goes to 100% on one core and the memory climbs as crazy… back to ff2 for me…
March 13, 2008 at 7:41 am
cross-posting this here as well:
Ran the tests on my own rig, Athlon XP 3k+, 1.25 GB Ram, Windows XP SP2, which should be representative of quite a few people:
— IE8 just completly splurges: http://208.100.30.120/dwarf/ie8.png
— Safari somehow runs the test very oddly, always closing all windows before opening the next batch, and eventually crashes: http://208.100.30.120/dwarf/safari.png
— Firefox 3 Beta 4 runs it as expected, with a peak of 197 MB, an average of 190 MB and an end of 65 MB: http://208.100.30.120/dwarf/firefox.png
— Opera 9.5 Beta 1 with the memory cache set to automatic runs it a bit worse, and stalls on the VDO Cars page sometimes, thus the hiccups in the graphs. Peak of 213 MB, average of 190 MB and an end of 163 MB: http://208.100.30.120/dwarf/opera_default.png
— Opera 9.5 Beta 1 with the memory cache set to the lowest setting of 4 MB still stalls on VDO sometimes, gets a better memory usage though. Peak of 184 MB, average of 170 MB and end of 128 MB: http://208.100.30.120/dwarf/opera_low_cache.png
Note: the numbers in the graph are each of the highest peak in the graph, while the measurement at the left is the current value.
Also note that the higher end value of Opera is down to an undo cache which can restore a closed tab completely from cache, without touching the web server at all.
March 13, 2008 at 7:51 am
Sounds good so far.
Can’t wait for the final version.
March 13, 2008 at 7:53 am
This just confirms that firefox is bigger and better than internet explorer. Firefox two needed to be upped a level and this article is a wonderful explanation.
Pull the others along with you!
March 13, 2008 at 8:16 am
[...] if you use for an extended period and sometimes may just hang. Anyway, Firefox 3.0 claims to have solved this problem. It also has a snazzy “intelligent” location bar where options will pop up when you [...]
March 13, 2008 at 8:36 am
Outstanding…………….well done!!
Be well………
March 13, 2008 at 8:37 am
Also, FF2 seems to have everyone beat with an actual average of 170 MB …
http://208.100.30.120/dwarf/ff2.png
March 13, 2008 at 9:28 am
[...] pavlov.net: Firefox 3 Memory Usage [...]
March 13, 2008 at 9:45 am
Hi,
Thanks for describing all features frnd.
March 13, 2008 at 10:09 am
@hokkos: I can confirm that behavior with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031304 Minefield/3.0b5pre. Have you reported this issue?
March 13, 2008 at 10:18 am
Great work!
I’d be curious to have the same test done with FF2, FF3beta, Safari and Camino on a Mac. If you have any idea how I could measure memory-usage of an app over time on MacOS please let me know and I’ll be glad to make a test myself and share the results (I’d also need the exact sequence of URLs you used for the test).
Bye.
March 13, 2008 at 10:51 am
[...] Apparently, that has changed, according to some tests prominently displaye