Chrome and Firefox 3.5 Memory Usage(dotnetperls.com)
dotnetperls.com
Chrome and Firefox 3.5 Memory Usage
http://dotnetperls.com/chrome-memory
45 comments
I agree. Closing firefox through file->quit takes at least 30 seconds for me, during which I can hear the laptop's fan spinning up.
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.
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.
C/C++ programs that manually memory free at exit are doing it wrong.
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.
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.
SIGKILL? Uh, you know there is a little function called exit() that exits the program.
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.
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.
SIGKILL because it gives finalizers and at-exit handlers no chance to run. The building has been emptied: knock it down, don't waste time picking it apart brick by brick.
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.
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.
Ah, right. I wasn't thinking of C++ destructors, since I usually program in C these days. In that case, you're probably right.
Could be some plugins rather than FF itself?
It's possible, I suppose, but I seem to remember that it happened long before I added any extensions (I don't have very many - 2 or 3 of the more popular ones like adblock and firebug). I guess it wouldn't hurt to experiment again.
I had it very infrequently, and I have only 3 plugins installed. Haven't experienced it since I have a "click for flash" plugin. I still suspect that it was one of the may sites I kept open that brought down FF. The browser should prevent that, but if a site can bring down FF, it would be more like a bug than a general shortcoming of FF.
It's definitely not reproducable like "open 20 tabs and FF will slow to a crawl".
It's definitely not reproducable like "open 20 tabs and FF will slow to a crawl".
I always had that problem with Firefox prior to Firefox 2 and continued to have it with the first several releases of Firefox 2. After some update to Firefox 2 I never saw it again. I would call you crazy or a liar for reporting it with FF3 except that I remember being called (essentially) crazy or a liar when I complained about that problem with early releases of Firefox 2. Plus ça change, I guess.
Are you using the latest FF 3.5 release candidate? I noticed this issue with previous versions, but it seems like the latest RC is much better.
I am. And granted its memory management is getting better with each release (memory usage improved greatly from 2 to 3). Admittedly, I haven't had 3.5 RC long enough for a very extensive experience. I'm speaking primarily of FF3, which for me could get quite painful even switching tabs (especially with Gmail open on one tab). It could be better, but 3.5 RC has only been out a few days. At first, I loved the shit out of FF3, but after a while, I found myself getting furious (at least working on my laptop; on my desktop, which is a beastly gaming machine, I don't have nearly as many complaints).
I found the same problem with FF3, which prompted me to try the 3.5 releases.
I haven't had the problem of sluggish old Firefox processes for years -- because it crashes on me at least 10 times per week.
Private bytes or address space? Shared readonly counted twice?
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.
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.
Why don't you like Chrome's tab design? I was a little off-put when I first saw it, but it makes sense for tabs to live at the top edge of the screen from a Fitt's Law perspective: when you move your mouse upwards to interact with the browser, it's to deal with tabs (so they deserve the larger target). When you want to hit the address bar, you hit ctrl+t to get a new tab in which it's already selected.
Tabs have always seemed like a horrible misfeature to me. The OS already provides a taskbar, so now you've created N*M places to look. Not only that but you can't see all the tabs at the same time once there's multiple windows, so you have to pick a window, check all of its tabs, move to the next and repeat. The "it's like MDI/documents/text editors" argument is bogus because the window that contains gmail has nothing to do with the window that contains HN, or reader.google, or whatever. It's like all the programs written in C++ get their own taskbar, separate from the ones written in VB, separate from the ones written in JS. Except we only separate the JS ones for some reason.
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.
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.
The lack of top-left corner double-click drove me nuuuuts. Until I found out that you could middle-click to close tabs.
Is the huge memory use from Chrome just because it opens separate processes for each tab? If so, can't some of that memory actually be shared by the OS even though it shows up as duplicated (like what happens if you do vfork?)
Nope - the huge memory usage for Chrome is because this analysis is complete rubbish - it's double counting all the shared memory for each process, as you suggested.
He is using Process.PrivateMemorySize64 in .NET. It doesn't double-count, because it only counts non-shared pages.
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:
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
He talks about his utility on this page:
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:
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);Just to note - this is done on Vista, which means that the browser stats may look very different on a different OS.
I don't know if this is relevant or not, but Safari uses OSX's ported libraries as DLLs. If the memory size of those DLLs is being used, it would show up as less memory usage on an OSX machine due to those libraries being a shared part of the main OS.
Probably the ratio is to stay, since the other platforms are treated with the same indifference by the developers.
Chromium dev list discusses these results:
http://groups.google.com/group/chromium-dev/browse_thread/th...
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.
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.
4 GB of memory can be had for $50.
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.
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.
I also want my browser to be fast and responsive, but the current trend goes in the other direction. How on Earth can you occupy GBs of memory? How much time does it even take to download a gigabyte of data?
Of course, it's not the actual downloaded text that takes up all that memory. It's not like programs take up gobs of memory because the programmers were being lazy and disdainful.
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.
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.
That is obvious. What is less obvious is how much memory you can waste for the internal representation. I would expect that the memory footprint of a well-designed browser should be dominated roughly by the download size (w/out taking into account the javascript code, which could keep a lot of state around).
> should be dominated roughly by the download size
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.
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.
Sadly the majority of motherboards out there can't handle more than 8GB of memory. Single 4GB chips around $80 now (fully buffered), so it should seem like normal motherboards with 4 slots should support 16GB normally.
what about firefox + firebug compared to chrome?
You mean compared to Chrome + Firebug Lite? http://getfirebug.com/lite.html
oh cool hadn't heard of that !
Ok, but how to interpret the results? If the memory is not used, it is a problem that Chrome takes up so much of it?
The problem is that the memory is used by other programs when I want to start them up.
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.
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.
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
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?
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?
Yes, to a certain degree. The problem is that it would be cheaper to, say, drop a decoded version of a JPEG and re-decode it, instead of having it get swapped out. In fact, I suspect that for large images, it would be cheaper to re-read the compressed jpeg and decompress it than to read back a larger swapped out decompressed version, just because hitting the disk is slow, and swap tends to get fragmented because it's usually written a few pages at a time.
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.
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.
Oh, another big problem is that you need to actually write the data you're swapping out to disk. You can't just drop it on the floor whenever memory pressure is high; You have to wait for the disk so spin up, seek, write, and so on.
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."
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."
You really can't compare a beta or Release Candidate with final versions of other browsers that most definitely will put your numbers off.
Do you have any strong data stating that the final release of some software is in general more memory friendly as opposed to the beta version? I don't have data for the counterpoint either, but I'm willing to bet the developers have other priorities (i.e. bug fixes as opposed to optimization). Once you've maldesigned your software w.r.t. performance, you can't do much except to wait for hardware to catch up.
Beta versions of software include debug information. This is pretty much a standard practice, even I do it. It helps me understand where things went wrong and how it could be improved. When you do the final version you generally get rid of the debug information which more often than not will reduce memory consumption. This is different from optimization.
I doubt the beta comes with debug information (not your beta, theirs). I don't use Windows -- it should be easily checkable by someone who does.
[deleted]
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.