Chrome and Firefox 3.5 Memory Usage
dotnetperls.com
dotnetperls.com
My problem with Firefox has always been with having the browser open for a long time (days) and running multiple tabs, including having an open Gmail window constantly.
By that point, Firefox is always sluggish and painful. Closing the browser the natural is a waste of time because it takes so long for the memory to free up, and killing the process altogether is the only thing that does anything to buy me some clock cycles.
I'd like to see the results of a long-term test of that nature.
Usually I just kill -9 it because I don't have the patience to wait.
Firefox 3.0.11, on a dual-core low-voltage laptop with 1 gig of ram. It's fast enough to run everything I care about but firefox.
They ought to (1) write everything to disk they need to save (2) fsync (3) send themselves a SIGKILL. The OS will tidy up the memory.
Other than that, yes, I agree with you, but I suspect what's actually taking all the time is paging back in the data that it wants to write to disk when it syncs, and not necessarily freeing the memory.
I doubt that paging all the stuff it wants to write is the reason. If that were the case, killing it during the grind would corrupt its save files, and the time duration of the grind would be proportional to what needs saving (just a few files of fairly constant size) versus proportional to how much memory it's hogging.
I think it's paging all right - it's paging back in every fiddling little object to call its finalizer.
It's definitely not reproducable like "open 20 tabs and FF will slow to a crawl".
I happily suffer Chrome's stupid tab design and lack of Flash (on Ubuntu) for much better end-to-end performance, whether it takes up more memory or not.
For Chrome specifically:
1) it lacks the option "New pages should open in [X] a new window [ ] a new tab" compared to Firefox, which makes tabs ignorable.
2) On Windows, I'd much rather they follow the OS conventions for MDI rather than make up their own "cool"/"clever" one (see media/audio players, for some random reason). All of a sudden, for example, you can't double-click in the top left to close. Well, way to be clever, but that's crap.
Non-shared working set pages are probably the most relevant measure, as a process-per-tab model will have lots of address space and may use memory mapping extensively, and so have lots of non-shared pages, but not actually touch many of those pages, and end up with a relatively small working set. However, .NET's Process class doesn't have an equivalent property to Process Explorer's "WS Private" column.
EDIT: Sure enough, a quick eyeball of some Chrome subprocesses using Process Explorer gives me these results:
Private WS Private
1416 460
14916 7952
12084 9780
16780 13972
16164 11336
14812 12040
10284 4444
19140 15400
http://dotnetperls.com/browser-memory
"It uses the PrivateMemorySize64 long value from the Process collection in .NET."
You can get his memory watcher from this page:
http://code.google.com/p/dotnetperls-controls/downloads/list
The relevant lines from the "MemoryClass" class:
long size = singleProcess.PrivateMemorySize64;
double megabytes = ConvertBytesToMegabytes(size);TLDR: Vista's default memory readout is actually pretty good for simply adding together like this and getting reasonable numbers WRT shared libs. Chrome really does use tons more memory than FF 3.5 with simple pages in many tabs. Chrome devs chose stability, security and foreground tab prioritization over lower mem use on purpose. They don't think this test much reflects what people actually do with their browsers.
When I use a computer I usually use: browser + music, OR browser + emacs.
I want my browser to be fast and responsive, and the memory isn't being used for anything else.
No, it's the internal representation of the markup, and the program state of all of the javascript programs a page might incorporate, that takes up a lot of memory.
Well, judging by the graphs in the linked article this is clearly something that every browser vendor experiences. I imagine that the trade off in speedy page rendering is having a lot of memory intensive data structures.
It's prolly more complicated than we give them credit for.
I've never liked the griping about memory use - if you're not swapping out to disk then you're perfectly fine. I'm much more concerned with having firefox occupying a whole core if I leave it unattended with too many js intensive tabs open.
Don't get me wrong, caches are great. However, it's one thing for the OS to cache stuff, because it can easily drop caches when memory pressure rises. Userspace software in current systems have no good way of knowing the memory pressure, and no good way of responding to it by dropping caches to free up memory. (yes, an API for "this memory is a droppable-at-any-time cache" would be nice in OSes, but it doesn't exist at the moment, and getting one that's easy to use would be hard).
More or less, that means that software that uses more memory in userspace causes swapping and lame performance. And honestly, there is no good reason for a browser to easily be the most resource intensive program on my system. Even games tend to be far lighter than browsers.
Naive question: would this be any better than letting applications provide swapping hints to the OS? And is that any better than just letting the OS swap based on usage?
Swap hints probably aren't really worth the effort, although I haven't benchmarked it.
The idea behind caches is to avoid doing expensive operations repeatedly, and hitting swap is about as expensive as an operation can get.
What you really want is to be able to tell the OS "I don't care if this data goes away. If you need space, don't bother taking time to save it, I can regenerate it quickly."