Hacker Newsnew | comments | ask | jobs | submitlogin
AndrewDucker 482 days ago | link | parent

Firefox isn't quite as good as Chrome when it comes to retrieving memory, but it's much better than it used to be. And it's vastly better than Chrome when you have those tabs open: http://techlogon.com/2012/09/21/review-of-firefox-chrome-and...


justinschuh 482 days ago | link

I have no idea what that link is supposed to be demonstrating. It doesn't say how they measured memory usage (private working set, address space, ouija board stacks?) and doesn't share any of their data sets. It's an arbitrary set of claims devoid of substantiating context, and as someone who has measured this before, it doesn't appear to align with reality.

The fact is that single process versus multiprocess carries different tradeoffs with respect to memory. A single process has an advantage in the short run, in that it will consume less memory initially. However, in terms of private working set memory across multiple tabs you're simply not going to see anything like the 2x claimed in that link, given that much of the address space maps to shared pages. So, most likely the authors just weren't properly measuring memory usage per-browser.

On the flip side, a multi-process architecture has its own strong advantages for memory consumption. Any complex, long-running application is going to have to contend with memory leaks and fragmentation, which exert increasing memory pressure over the life of an active process. This gets even more painful when considering the multitude of heaps in your average browser, chrome layers written in Web technologies, and (iirc) Firefox using a non-moving, non-generational GC. Whereas a multi-process browser has a vastly cleaner solution to all of that: it simply disposes of an entire address space (including all fragments and leaks) when it's done with a rendering context.

Now, I don't want to undermine the really great work that the Mozilla guys have done addressing leaks and fragmentation, with things like cycle detection, JavaScript compartments, and various detection and analysis tools. However, the simple fact is that users who keep their browsers open for many hours, days, or weeks at a time are generally going to suffer from these issues more under Firefox than Chrome or protected mode IE.

-----

pcwalton 479 days ago | link

"This gets even more painful when considering the multitude of heaps in your average browser, chrome layers written in Web technologies, and (iirc) Firefox using a non-moving, non-generational GC. Whereas a multi-process browser has a vastly cleaner solution to all of that: it simply disposes of an entire address space (including all fragments and leaks) when it's done with a rendering context."

You're overstating the impact of JS here. JS memory is allocated in large "chunks" in Firefox. This minimizes external fragmentation. When a rendering context is destroyed, all of the chunks are immediately destroyed with it; because of compartments, we know that there are no chrome JS objects interspersed with the content JS objects, so we can just destroy these large chunks. So the amount of JS-related fragmentation resulting from closing rendering contexts is minimal in practice.

Regarding chrome layers written in Web technologies, this is somewhat orthogonal, since in all browsers chrome allocations stick around for the lifetime of the browser. C++ code has no compaction story, and, unlike JS, it has no reasonable path to achieve compaction in the future.

-----




Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: