6 ms·

Well, plugs _a_ leak. The Memshrink team has plugged an awful lot of leaks, and slimmed down an awful lot of code over the last year or so. They've now hit th

Well, plugs _a_ leak. The Memshrink team has plugged an awful lot of leaks, and slimmed down an awful lot of code over the last year or so. They've now hit the point where they're largely fixing bugs in add-on writer's code, rather than their own.

corin_ 15y ago
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.
- AndrewDucker 15y ago
  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. More here: http://blog.kylehuey.com/post/21892343371/fixing-the-memory-leak http://blog.kylehuey.com/post/21892343371/fixing-the-memory-...
- lillycat 15y ago
  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).
  - khuey 15y ago
    Actually it's looking like most of the breakage can be avoided by a simple change on our side.
pbiggar 15y ago
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.
- diminish 15y ago
  At my Linux firefox I am seeing better and better performance, thanks the team.
rrreese 15y ago
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?
- lillycat 15y ago
  Since months (I would say Firefox 7), Firefox is better than Chrome when used with a lot of tabs.
- robin_reala 15y ago
  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…
  - corin_ 15y ago
    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.
    - robin_reala 15y ago
      Realised that after I posted. Still, as you said this shows that Firefox has come a long way since the 4 days.

corin_ 15y ago

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.

AndrewDucker 15y ago
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. More here: http://blog.kylehuey.com/post/21892343371/fixing-the-memory-leak http://blog.kylehuey.com/post/21892343371/fixing-the-memory-...
lillycat 15y ago
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).
- khuey 15y ago
  Actually it's looking like most of the breakage can be avoided by a simple change on our side.

pbiggar 15y ago

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.

diminish 15y ago
At my Linux firefox I am seeing better and better performance, thanks the team.

rrreese 15y ago

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?

lillycat 15y ago
Since months (I would say Firefox 7), Firefox is better than Chrome when used with a lot of tabs.
robin_reala 15y ago
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…
- corin_ 15y ago
  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.
  - robin_reala 15y ago
    Realised that after I posted. Still, as you said this shows that Firefox has come a long way since the 4 days.