Firefox Notably Improved In Tom's Hardware's Latest Browser Showdown 218
Billly Gates writes "Tom's Hardware did another benchmark showdown, since several releases of both Firefox and Chrome came out since their last one. Did Mozilla clean up its act and listen to its users? The test results are listed here. Firefox 13.01 uses the least amount of RAM with 40 tabs opened, while Chrome uses the highest (surprisingly). Overall, Firefox scored medium for memory efficiency, which measures RAM released after tabs are closed. Also surprising: IE 9 is still king of the lowest RAM usage for just one tab. Bear in mind that these tests were benchmarked in Windows 7. Windows XP and Linux users will have different results, due to differences in memory management. It is too bad IE 10, which is almost finished, wasn't available to benchmark." Safari and Opera are also along for the fight.
Why IE9 did well (Score:5, Insightful)
RAM Usage (Score:3, Insightful)
Let's get a grip here people, it's 2012. If your computer doesn't have 4-8 gigs of ddr3 ram, you're doing it wrong. Chrome is allowed to use as much memory as it wants as long as it gets the job done better than anyone else.
Re:Too bad for others (Score:3, Insightful)
You assume that those memory management problems were both easy to spot and fix. They weren't.
Kudos for the Firefox devs for finally improving the memory usage situation.
Re:Too bad for others (Score:5, Insightful)
No, he's saying that a screw up long ago prevents him from ever looking at it again.
Its the old "cut off your nose to spite your face method" of software selection. There is no redemption in some people's eyes.
Re:who gives a fuck (Score:5, Insightful)
Why "enterprises" can't customize open source software is a bit of a mystery to me. Interns really are cheap these days (esp. by $$$ enterprise $$$ standards). Seriously enterprise customers want a browser specifically tailored to their needs for absolutely nothing. It's funny.
Auto updates can be turned off both at compile time option and as an installed option. It's never been easier to bring in a custom patch set and build software and yet they're still bitch'n. They don't even have to pay a fucking license fee but act as if they're paying customers. They act like they dished out thousands of dollars for support like they do for their Oracle database software or Microsoft servers. They'll pay MS and Oracle per processor/core for less customization but when it comes to Mozilla they expect $0.00 to get them everything.
Enterprise babies need to grow up and L2.
Re:What the summary did not include (Score:5, Insightful)
Is there anything of value to comment on when the page load times are so close to each other on all the browsers excepting the last? The first 4 finishers range from 880ms to 947ms, which is less than a 10% differential across 8 websites. I doubt you'd notice any difference in your day-to-day real life browsing with respect to page load times.
Re:more information on firefox (Score:5, Insightful)
As I see it, the biggest complaints about memory usage seem to be coming from a demographic of people who aren't using their system in a resource-friendly manner.
People should not need to do that. Quit trying to force me to adapt to the machine instead of the other way round. This isn't a Sinclair Spectrum, it should be able to handle 40 tabs without crashing or filling up all my RAM.
Workset and memory usage (Score:5, Insightful)
The main problem with this article is that it seems like the authors are simply reporting the compound number for Memory - Working Set for all browser processes. This is problematic in so many ways it ain't even funny. Foremost, multiple processes requiring the same page mapped into RAM will count that page multiple times. With architectures involving a lot of cross-process communication and multiple instances, like IE and Chrome, all code pages that are mapped into multiple processes will be counted multiple times (including any Windows OS DLLs mapped by IE), as long as they are part of the active working set. In addition some of the inter-process communication is probably handled by mapping common regions of memory, and thus also counted multiple times.
So, in one sense, IE and Chrome are losing out big in the multi-tab test. On the other hand, when tabs are closed, the related processes are also completely closed. This means that the associated heap is returned in full. In Firefox, even if some regions of the heap are freed back to the OS, Windows will not actively reclaim that working set. Slowly, the untouched pages will be removed and replaced by caching, but if there is no memory load, the best guess by the OS is that a process that just used a lot of memory and freed it might start doing it again. It is possible that Firefox, due to the monolithic process structure, ends up with a more fragmented heap (or a heap implementation that is not returning pages to the OS) so the OS could not successfully reclaim the pages (and only page them out to disk as a last resort), but we do not know that from these tests. It is easy to try this yourself, write up some small C program allocating a big buffer, freeing it and then pausing for a scanf/gets or something.
It is relatively easy to measure CPU usage or amount of I/O. Total time usage is also easy to measure and it says something about the conditions even under load. Memory is quite different. Memory is allocated all the time and the total bandwidth usage is closely related to the actual computations of the CPU. Even in a fully virtualized environment, the hypervisor cannot keep too detailed stats on memory usage - the overhead would balloon. At the same time, memory is a constrained resource with complicated temporal dependencies. You cannot free some memory from a process now and just give it back later. And when you bring multiple related processes into the mix, what you measure is all depending on how you define your tests. In many situations, the best metric is probably to look at full system metrics anyway, i.e. delta on total available/free memory in Windows. Many of the same issues will still apply, though. The question really becomes why you are interested in memory usage. If you want to know how the OS will behave when another process is allocating a lot of memory, test for that and verify memory usage as well as load times when you bring back the browser.