Very true. There's been a massive amount of work put in by the MemShrink team. But it looks like they've found the holy grail this time; look at the numbers: 800MB vs 230MB. That's a big big deal.
This sounds great, I stopped using Firefox just over a year ago due to its fairly heavy memory usage. I usually run with 20+ tabs and even on a machine with 4GB of ram it was pretty unpleasant.
How are you current Firefox users finding the RAM usage, especially compared to Chrome?
I’ve just killed and restarted Firefox, then duped my current set of tabs over to Chrome (in-house jukebox using websockets, a slideshare presentation, couple of open Google Docs spreadsheets, a Pivotal tracker session, a couple of tabs of a local development project, Google Plus, and this HN thread). Totalling up ‘Real mem’ in Activity Monitor shows Chrome 18 using 735.4mb (of which 33mb is Flash). Firefox 13 (beta release to be fair) is coming in at 450mb (of which 65mb is Flash).
The internal memory measurements (about:memory) come out as 835mb resident for Chrome, and 324mb (of ‘explicit’, whatever that is) for Firefox.
I’m not using any extensions in Chrome. In Firefox I’ve got installed Firebug, FireFontFamily, FireQuery, Lastpass, PDF.js and QuickJava.
Edit: oops, missed cloning a tab with a video in over to Chrome. That explains the disparity in Flash, and you could probably expect to increase Chrome’s real mem usage a little had I not closed it already…
This bug fix won't make much of a change right after starting Firefox, it just prevents memory from building up over time due to closed tabs. Additionally it's effective in nightly builds not beta, so 15.0a1 not 13.
Your comparison is useful overall, but not relevant to this change.
With Firebug installed, you most likely have JIT disabled http://antennasoft.net/robcee/2009/12/15/firebug-and-the-jit.... I would suggest you use a separate 'webdev' profile for such things (the inbuilt web console that is now in firefox is also getting there).
That was true in 2009 but was fixed in January 2010: https://bugzilla.mozilla.org/show_bug.cgi?id=534120#c52 (although it’s true that if you’re actively debugging scripts the JIT turns off - Firebug has the script panel off by default)
Incredible, I've been doing all my browsing for the past year with the script and console panels activated and had no idea that it was disabling the JIT for every page that I visited. Just turned them off, and I can't believe how accustomed I'd become to sluggish webpages. Thanks for the link!
> How are you current Firefox users finding the RAM usage, especially compared to Chrome?
I'm fairly sure that multiple studies have shown that Chrome uses more RAM than Firefox. But that's not what's important - all that matters is whether the browser appears snappy to the user. That's much more so the case with Chrome than it is with Firefox.
That's correct. Snappiness is what really is important. Mozilla conduct a parallel project called Snappy to improve that specific metric.
Note that Memory consumption is somewhat related to Snappiness: if it is too high, the program will slow down (paging, longer garbage collecting pauses, ...) and feel less snappy.
I don't think memory's the bottleneck on most modern systems, so it seems like Google made the right choice by allowing greater memory usage in return for better end-user performance.
You're right in that Google's made excellent engineering tradeoffs to keep Chrome snappy, but note that memory is, sort of, the bottleneck on modern systems. Specifically, the channel between memory and the CPU:
I'm not sure exactly why this happens, but it does use a lot more memory than you'd expect. Right now, I have 13 Chrome tabs open, Mail.app, a Terminal session, Colloquy, and TextWrangler running but with no documents, but it has 1.14 GB wired (as in, can't swap) and 1.66 GB active. That's a total of 2.80 GB memory in use.
But also, it takes a while to swap (upon which it beachballs all over the place), and it's not very intelligent about when to swap.
It's a 2.00 GHz quad-core machine, so I have plenty of CPU power. It's just that when I get working on more than one or two things at once, switching between them swaps everything to heck.
"Recently Closed Windows" is even better, for those times when you accidentally manage to close your main browser window with 200 open tabs, expecting Firefox to restore them the next time you start the browser, without realizing that you have a dinky little popup window left over somewhere.
But also note that Opera's had a Recently Closed Tabs dialog for as long as I can remember.
Chrome uses more memory, but for good reason. I think they load more stuff in RAM so the browser works faster, and there's also the sandbox security feature, which makes it so tabs don't share memory, so that must add quite a bit, too. That being said, I wouldn't mind if the Chrome team worked on optimizing RAM usage as well, if they aren't doing it already.
What is the basis of your belief that their increased memory usage is because they "load more stuff in RAM so the browser works faster"? In my experience working on MemShrink, almost all of the things we have fixed are the browser using more memory for no particularly good reason, and I would be surprised if this wasn't also the case in Chrome. You are right that sandboxing does incur some overhead, but I'm not sure how much. But I agree with your overall point, that memory usage is by itself is not as important as overall system performance.
Is that actually the case, or is it that the leak they've fixed is related to the add-ons API? I've only really glanced at the patch discussion thread, and this isn't an area I understand all that well anyway, but the way it reads to me is as the latter - hopefully someone can explain why I'm either write or wrong on that, though.
They did both. The leak was in numereous add-ons code, but they were able to change the semantics of the API to remove all these leaks. But that breaks things in some edge cases, but that was deemed acceptable (one time fix in some extensions, mainly those using Jetpack needing to embed the latest versions).
So far as I understand, there was a change made which cut off a leak between add-ons and the tabs/windows they were attached to, so that closed tabs weren't being held in memory just because an add-on had a reference to them.
However, that change broke something in earlier versions of the Add-on SDK, which means that at least one Add-on was then leaking memory like crazy. Upgrading that add-on to the latest version fixed _that_ leak.
They've now hit the point where they're largely fixing bugs in add-on writer's code, rather than their own.