Slashdot Mirror
Memory Usage of Chrome, Firefox 3.5, et al.
An anonymous reader writes "This experiment graphs the memory usage of Chrome and Firefox 3.5 (along with Safari and Opera) over a series of 150 Web page loads using an automated script. Firefox 3.5 shows the lowest memory usage in all categories, including average memory usage, maximum memory usage, and final memory usage. Chrome uses over 1 GB of memory due to its process architecture. Safari 4 and Opera show memory usage degradation over time, while Chrome and Firefox 3.5 are more reliable in freeing memory to the OS." IE 8 was not included "because the author could not find a way to prevent it from opening a new window on each invocation of the command."
I couldn't find a way to keep it from sucking so forcefully all the air was evacuated from my office every time it was run.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
Finally, this should stop perennial "firefox is a memory hog" trolls. Hopefully.
Unless you are talking about a system with severely limited memory, memory usage is probably not the right criteria for deciding which browser to use.
Something like "it doesn't show weird ass icons and bars when Slashdot decides to change CSS" is probably much more important. Firefox 3 totally screws up Slashdot in Default mode.
We all know that the thing that hogs the most memory in Firefox is all the extensions that people use to immitate other browsers... Who actually uses Firefox without a single extension and brags about how good it is anyway?
I use Firefox and Safari regularly. I use two web browsers because each one does something vastly better than the other. Firefox for porn and online transactions, Safari for basic day-to-day anything that might include bookmark management (long story short, every browser I've used EXCEPT safari still does bookmark management using some variant of the horrific Netscape method - this includes IE, Mozilla, Firefox, etc - whereas Safari is the first browser I've used that does it in a non-bullshit fashion). However, useable as it is for bookmarks, Safari's a dick when it comes to password management and a few other things - most notably, how the browser handles while the system is paging out or otherwise shot in the ass with RAM overuse from other applications.
Long story short, under ANY kind of system load - we're talking ANYTHING above IDLE - Firefox is more responsive than Safari. When the system is shitting gold plated bricks trying to deal with the demands After Effects or Photoshop or Final Cut Pro is putting on it, Safari is beyond useless... and Firefox is responsive.
It all boils down to memory usage. Specifically, Swap/pagefile useage. On the Mac, firefox seems to be more responsive under load while safari is LESS responsive under the same conditions - it has ultimately has nothing to do with RAM usage and everything to do with how the respective applications use swap/pagefile.
Eat as much ram as you like... but until Apple does something about disk I/O, stay the HELL away from swap - or I'll use the application that does. (namely, Firefox.)
... and is the difference between Firefox, Opera and Safari basically how efficient they are at freeing memory that's no longer used?
I’m old enough to remember 16K of memory being described as “whopping”
Summing the memory usage of all the Chrome processes is probably not the correct thing to do, as the memory usage indicated most likely includes shared libraries. I can't say this for sure about Vista, but on all sane operating systems, each shared library is loaded only once into memory, and then shared among different running programs.
Opera Unite! To help free the Iranian strangle hold on information!! ;-)
Then a few years later we end up wondering how come our software now sucks ten times more ram than before despite no corresponding quantum leap in functionality.
IIRC its possible to instruct Chrome to not use its process-per-tab model via a command line option. Can't remember what it is, but I remember reading it existed. It seems likely that Chrome would have used less memory when running in that mode.
I'm glad to hear that Firefox has finally improved its memory usage. Although my system has plenty of memory, I still find that the amount of memory FF3 requires causes a very annoying slowdown.
Of late, I've been using Midori as an alternative. With it's current git version and a recent WebKit build (r44951), I've found it to perform better than any other browser I've used (opera, konqueror, firefox). Although it does have a few minor kinks, it supports pretty much every site I've come across and works considerably better with mozilla plugins (namely, flash) than Konqueror and Opera.
Currently with an instance I've been using for the last few days, Midori is using 77 MBs of memory (for comparison, my other running browsers: opera- 120 MBs, Konqueror- 91 MBs, Firefox- 119 MBs). I didn't do any even moderately sophisticated benchmarks suck as those in the article, but that beats the average and final amounts of memory of FF3.5 as shown in the article. Obviously this is not Windows-friendly, but I'd say Midori deserves some more attention, considering that (for me, at least) it outperforms all the other major browsers.
Is the Linux version of Firefox particularly horrid or something? When using more than 10 tabs or so, my memory usage is typically in the 600mb+ range. It's currently taking 1.1g resident for about 40 tabs. I'm on x86-64, but even if we assume there's a full doubling of RAM usage due to the architecture, that's still 550mb equivalent, which his test never hits even with 150 tabs.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Desktops are passe. Now people want browsers to run on netbooks, phones and such.
There's no answer that's always right. If memory usage was paramount, we'd all have browsers that used 1 MB of RAM and took 10 minutes to render a page, with another 2 minutes to scroll down a page.
But RAM is cheap and developers have to make compromises based on the real-world that they have to compete in. I can get a gig of RAM for about the cost of a burger lunch with my wife.
Do I really care about memory usage? Only to the extent that it's 'good enough' on my slowest computer - a dual-core Mac Mini with 512MB.
FF3 is plenty good enough for me to thoroughly enjoy an episode of 'Burn Notice' on Hulu just now on that very computer.
Sorry you are having probs with memory usage on your (ancient?) computer. Perhaps you should consider forgoing a burger lunch this week?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
"In memory of Chrome" was how I first skimmed it
Table-ized A.I.
The author says he didn't included IE 8 because there was no way to start it without opening a new window for every invocation!
I would have preferred to have it included despite this "big drawback" and have this thing explained in a note.
A partially meaningful test (upper limit?) is always better than no test at all!
I fear that this omission is to "protect" bad performances even in comparison of a browser by a company which seems to be in deep competition with Microsoft.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
I live in tabs hell. I have... uncountable numbers of tabs open right now--over 9,000, probabaly. My Firefox memory usage can easily push 1400mb. When that happens I kill it and reload, and the memory resets at around 400-600mb.
Seeing this graph, I can only imagine what Chrome would do to me.
"I Don't Have Enough Faith to be an Atheist"
To all who bash Firefox, make sure you are using newest 3.5 and not some previous version.
It seams to me that lots of people haven't even recognized a small difference in number, but it is a big milestone for Firefox internally.
In the early days, more RAM meant that you could cache some frequently used information in memory instead of recomputing it or loading it on demand. But there's a diminishing return. Nowadays, it's usually faster to recompute than read it all back from RAM, and if an interactive program uses a lot of RAM, then it's likely keeping a lot of junk in memory that it doesn't need. That tells you that the programmers didn't think things through carefully, and they probably didn't optimize other things that matter either.
Did you read the article? Which phones run Vista? Which netbooks carry 4GB of memory? Per Wikipedia, by default, none - http://en.wikipedia.org/wiki/Comparison_of_netbooks
To quote:
"Problem. You are interested in how the Google Chrome 3.0 Dev, Firefox 3.5 RC, Safari 4.0 for Windows, and Opera 10b web browsers manage memory on the Windows Vista operating system over moderate usage"
The tests were all run on a Windows Vista machine with 4GB of memory. If someone wants to run tests for "netbooks, phones" or "such" then this isn't the machine to test on.
I am sure that this is true for all of the browsers, but in Opera's case...
The machine has 4GB in question and Opera is set to "automatic" for the memory cache (default). According to this article, this instructs Opera to use up to ~10% of the system memory. This is quite tunable based on the environment, so one could easily optimize for a low-end machine and have satasfactory performance. The browser using the memory effectively is the more interesting test, which this benchmark fails to determine. An interesting detail in the graphs is how sharp the memory reclaim cycles are, where the smoother indicates better memory management. The graphs indicate that Opera does a good job in this regard.
You test all the browsers except the most up-to-date version of the most popular one. In other words, the one that matters the most.
Benchmarks are for people who choose software. Only a small minority choose IE. In a way, IE8 was included. It failed to compete due to lack of necessary features.
Wow, I *wish* I could get Firefox 3.5 to use so little memory! As I write this Firefox is using 1821M VIRT, 944M RES...and I only have 23 tabs open! Firefox memory usage has always been abysmal for me. Does Firefox perform drastically differently on Linux than on Windows? I would be quite horrified if it actually performed better on Windows, but I don't understand how it possibly managed to be so low...I've never seen Firefox use less than .5G with even a few tabs open for a while... I realize my personal experience involves extensions, plugins and other things which suck of RAM, it still seems terribly high for me. If I leave it running for several days, it will peak 2G and I have to restart the browser.
It's great that in the future Firefox might be better, but here and now, the latest stable version is 3.0.11, and while Firefox has many redeeming qualities, speed, memory usage and general performance is not one of them.
Interesting to see that Opera is not the memory sipping, lightweight browser that it's proponents make it out to be.
If you're running a 64-bit version of Windows (Vista x64, etc), then give serious thought to running a 64-bit build of Firefox.
I've found this build to not only be noticably faster, but also infinitely more stable and less of a memory hog.
In terms of numbers, I've had only one crash in the last 8 months, and at the moment, it's using 159MB with 15 tabs open. I've never seen the official 32-bit build perform like that...
This is a false dichotomy. Most software that uses less RAM is actually also faster.
Nowadays, it's usually faster to recompute than read it all back from RAM, and if an interactive program uses a lot of RAM, then it's likely keeping a lot of junk in memory that it doesn't need.
Wow, this is a perfect example of completely misunderstanding memory-CPU tradeoffs. No. For a non-trivial amount of data, it is never cheaper to recompute the data, at access-time. It may be faster overall, as you might be able to use the freed RAM in a better way elsewhere, but it will never speed the accessing task up.
If you recompute the data constantly, it has to hit RAM and then read it back, unless you're dealing with a dataset small enough to be stored completely in cache, in which case this is a nonissue anyway. More caching is never a bad thing, so long as you set smart defaults for how the caching is done, and you allow the users to configure it. More RAM, in the hands of a smart developer, is a Good Thing (TM).
Disconnect and self-destruct, one bullet at a time.
I would like to see the CPU usage of different browsers tested. I run Firefox 3.5b and Safari 4 on OS X 10.5, and with JUST ONE TAB open with gmail loaded, firefox uses 8% of the CPU sustained with bursts for some reason to 40%, and safari uses 1%.
With my usual workload, with like 40 tabs open among 5 or 6 windows, Firefox uses 40%, safari 4%. This is ridiculous! This means a lot when you're on a portable on battery, not to mention general system responsiveness.
I would like to see the CPU usage of browsers compared.
IE 8 was not included "because the author could not find a way to prevent it from opening a new window on each invocation of the command."
Did the author try Tools -> Internet Options -> Tabs -> Settings and change the option from the default "Always open pop-ups in a new window"?
I would really like to see this benchmark repeated with half and double of RAM available.
In these environments, memory allocation is an extremely important capacity planning criterion for application deployment.
\\ would love a Firefox addon or web proxy for remote desktop environments that dynamically rewrites the header of flash movies to allow globally reducing the playback frame rate to something arbitrary (like 2fps), as it would much more user-friendly than blocking flash altogether. I would site-license 1000 copies of that sucka tomorrow...
It depends, it depends on the size and boundary we are talking about, if it all fits in level 1 cache or level 2 cache it would definitely be faster in comparison to going back to memory.
New things are always on the horizon
Nowadays, it's usually faster to recompute than read it all back from RAM, and if an interactive program uses a lot of RAM, then it's likely keeping a lot of junk in memory that it doesn't need. That tells you that the programmers didn't think things through carefully, and they probably didn't optimize other things that matter either.
When I was doing real time stuff many years ago (when memory was a limited as hell and the CPU chugged along like a snail), calculations were never recomputed... given the tradeoff between memory use and CPU use (for recalculations) guess which one (it took a few cycles to check if a value was available to fetch opposed to a few hundred to calculate the value).
Your categorical denouncement of the previous post shows you do _not_ understand as much as you think.
The source data can often be _MUCH_ smaller than the resulting cached data, and as such reading the cached data from RAM can be more expensive than reading the source data plus processing it.
- These characters were randomly selected.
I'd love to see the memory management for Chrome, FF3.5, Safari 4 and Opera 10 when Snow Leopard arrives. Then I'd love to see how they compare to Windows 7 and see where work needs to be improved on both platforms.
By the end of the month, the most populair version is actually Firefox 3.0.x (IF Mozilla doesn't release 3.5), IE7 has a smaller market share, so does IE6 or IE8. It would actually have been really interresting to be able to compare 3.5 and 3.0 in the same test.
New things are always on the horizon
That's simply not true on modern computers. The CPU is often idle - it's starved for data, with the bottleneck being the buss that feeds it (RAM, generally). Add to this the fact that reading neighboring areas of DRAM is a much faster than randomly reading spots in in memory spread across whole megabytes (or gigabytes, even).
Compare recomputing something, where you never have to leave L1 cache, versus flushing the first few cache levels continuously to do spread-out reads of already-computed data. It's very likely, on a modern CPU, that the first will be faster.
Of course, this will vary considerably based on what your actual problem is, and you may be getting into bad "must hand-write assembly" cases which should generally be avoided, but... it is still true that computing every time is not only smaller, it's faster some of the time. For evidence of this, check how some people are finding compiling with -Os instead of -O2 actually produces faster code. In any case... trying to stuff a 1GB working set through the Von Neumann bottleneck is never going to produce an efficient and responsive program. Firefox is not exception here, though it's getting better with each release.
Ce n'est pas une signature automatique.
What the hell is up with Slashdot's CSS? I keep seeing images all over the comments (the bars used on the new comments section, the relationship icons). Is anyone else seeing them. I'm using Firefox 3.5.
Regards
elFarto
http://blog.codefront.net/2008/09/10/optimize-firefoxs-memory-usage-by-tweaking-session-preferences/
Check that link out guys - I did the caching tweaks, and it sped things up some, so I went back and used all the tweaks.
Let's remember that FF3.5 is still a beta. We should probably send feedback if we aren't happy.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I'm also not sure why ram is something that is worried about anymore. I don't find it important that firefox only uses 300mb or so of my 4GB.
That's nice for you.
An average user's system at the moment probably has les than 1GB of RAM; 512MB and 1GB (running on WinXP) are the most common configurations right now. 300MB on a 512MB system is intolerable for something that's basically a background process most people leave running all the time. It's barely acceptable on 1GB. I find that kind of usage tolerable on my 1.5GB system, but I often see Firefox with 500MB usage or even more (and I run flashblock, so I doubt it's flash that's responsible).
Basically, I would rather have faster software that takes advantage of the memory that I use, then slower software that avoids using it.
On a system high-end enough for 4GB RAM (i.e., you're presumably running on a 64 bit processor, and I would hope are using a 64 bit OS to go with it), I sincerely doubt you spend much (if any) time waiting for your browser to calculate stuff that could be readily accelerated by using extra memory. Chances are the only thing you ever wait for with your browser are slow javascripts and/or flash applications to run. It's irrelevant that the browser's cacheing an uncompressed copy of the images from the last 10 pages you viewed, because it would probably take your system less time to uncompress them from its compressed cache than it would for your monitor to update to show them.
I could have sworn that "et al" was "and others", whereas "etc" (et cetera) was "and the rest", it's only fairly recently that "etc" became generic and stood for both more, or the rest. And that "et al" was more of the same, but "etc" is more, but not necessarily the same...
Bob, Joe, Lisa... et al.
Ferrari, Mazda, Honda... et al.
Dogs, Butterflies, Plants... etc.
Plates, Bowls, Forks... etc
Considering this isn't all the browsers only some (most) of the main ones, "et al" is more correct than "etc", otherwise there would be at least 100 more browsers in this benchmark.
But, I could be wrong.
When I was doing real time stuff many years ago (when memory was a limited as hell and the CPU chugged along like a snail), calculations were never recomputed... given the tradeoff between memory use and CPU use (for recalculations) guess which one (it took a few cycles to check if a value was available to fetch opposed to a few hundred to calculate the value).
Whereas modern desktop CPUs can typically execute somewhere between 2 and 3 instructions per CPU cycle and a single non-cached memory access will likely invoke latencies of around 10 bus cycles, with each bus cycle being somewhere between 6 and 10 CPU cycles -- that few cycles/hundred cycle tradeoff suddenly looks less clear cut.
If you can rely on the cached value being in CPU cache, then it's almost always a win. Otherwise, count how many instructions you need to calculate it: it may actually be faster to run up to about 300 instructions than going out to system memory to read it. You can calculate a lot of stuff in 300 instructions.
In a way, IE8 was included. It failed to compete due to lack of necessary features.
I'm sorry but like the author, you're talking out your fucking arse. The bit you need you'll find in Tools, Internet Options, Tabs where near the bottom you're given the option of how to open links from other programs.
I only please one person per day. Today is not your day. Tomorrow isn't looking good either. - Scott Adams
Opera usually doesn't go over 300 megs over days, but Firefox often goes to 1 giga in a matter of 2-3 days. Even if I close all tabs, it still hogs to this 1 giga. So I have to restert it, since I've got 2 gigs only.
Weird thing is that I use Firefox only for its firebug and debugging of intranet software (I'm developer), while Opera is for the rest - I've got very weak intel graphic card, so Firefox doesn't work very well.
But Opera isn't perfect either, when Firefox gets to it 1 gigs memory, Opera usually gets to its CPU eating process... not really sure why, but it just keeps my 2 cores at 100% until I restart it. I think it was the same for Opera 9.
I haven't tested FF3.5 for it yet, but if its fixed, then I'm gonna be happier :)
A common approach is to compress read only data in RAM instead of storing it in the clear. It takes CPU to uncompress on the fly, of course, but the savings in RAM footprint and the fact that uncompressing can be practically free (if the CPU was idling otherwise) makes this approach worth trying.
This is simply not true for things like web browsing. How are you going to "recompute" a web page the user visited 10 minutes ago? The only way to make going back to that page fast is to cache it. RAM is a fine way of caching things.
There are a variety of tradeoffs possible. Do we:
1 Just store the original HTML/compressed images? This was Netscape's original solution, and works reasonably well.
2 Store parsed HTML, to prevent a reparse stage being necessary when redisplaying the page?
3 Store uncompressed images, to prevent decompression being necessary when redisplaying the page?
4 Store the DOM and layout information, to prevent relayout being necessary when redisplaying the page?
5 Store an image of the page as it was shown to the user with their browser size/settings as they were when it was last shown?
Each of these successively takes less cpu time but uses more memory than the previous. Firefox does the latter, and I'm not at all convinced that is the right point in the tradeoff. Redrawing the page image from the DOM should take only a few milliseconds. Recalculating the DOM and layout is more intensive, but still not likely to take long. I'm not sure which of 3 or 4 I think is best, but I suspect it is one of those. Although even 2 is worth considering, as it is a substantial memory saving compared to 3, and probably wouldn't take too long.
I used to run 100s of tabs at a time (up to 300 at one point) on a 1gb RAM machine. This is proof of how bad my browsing habits are but also shows that the only browser capable of this right now is Opera.
Try it in Firefox and your PC will definitely grind to a halt. If you need extensions, use Firefox.
Efficient, Extensible, Correct
Pick two
Firefox - Extensible & Correct
Opera - Correct, Efficient
There is not the development community in Opera, despite supporting widgets.
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
But here's the thing, it's not clear cut why those things should be sitting in your web browser's process RAM. You already have a disk cache, and the operating system is probably keeping your frequently used files in unused RAM already (if all your programs leave enough of it for the OS to use).
If your web browser fills a huge chunk of RAM with cached opened media, then the OS has less ability to optimize what's going on in the computer. Moreover, the actual speed difference from displaying eg an image kept in process RAM vs streaming it from the filesystem might not be that big (if that section of the disk was cached in RAM by the OS).
Because it's a notable matter. Come on, just because it isn't THE issue, that doesn't mean nobody should do a comparison.
Why do Slashdotters love to complain about articles so much? :-P
Property is theft.
Those idiots who make blogs with 300 images 400 youtube links that are 600 pages high are idiots.
But they sure push FF to the limit.
Liberty freedom are no1, not dicks in suits.
That's simply not true on modern computers. The CPU is often idle - it's starved for data, with the bottleneck being the buss that feeds it (RAM, generally). Add to this the fact that reading neighboring areas of DRAM is a much faster than randomly reading spots in in memory spread across whole megabytes (or gigabytes, even).
For the discussion at hand, this is irrelevant. Browsers aren't recomputing trivial data with their time. Browsers are rendering images and text to image buffers and then displaying them on screen. Rendering graphics via software is always slow, and with things like alpha compositing in modern browsers like Firefox, it's getting even slower.
Real software developers have taken this into account; we cache glyphs, we cache images, we cache rendered sections, we cache anything we can cache. Which is why viewing a webpage you've viewed before in Firefox is usually a task that resolves faster than you can see, but eats up a bit more RAM.
Lastly, you're throwing away one other concern, which is supremely important to people today. Whenever the processor is idle, it's using very, very little power. The longer the processor stays in that state, the less power is used and the less power is dissipated. Less power, more battery life, cooler server rooms, etc.
It's a tradeoff. It will always be a tradeoff. Sometimes it's cheaper to recompute, especially if RAM is the bottleneck, which it isn't anymore; if you're simply unicode lookups or hacking buffers together, fine, throw the RAM away when you're done. Other times, like rendering pages of high quality anti-aliased text, you don't want to be doing that every time through if you can help it, so you render to an A8 buffer and throw it in a LRU.
I feel the same way about CPUs. We're always seeing comparisons of the latest rivals. But personally, just sometimes, I'd like to comparisons of new versions versus old versions - whether that is latest releases of browsers or the Phenom IIs vs. old Athlon dual cores. I want to see progress because without that context it's hard to judge actual value. If we see that Firefox 3.5 is better than IE8, that's good to know. But what if they're both vastly superior to Firefox 3.0. Or that there really isn't much difference.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
As far as your 'average user' specs..
..with 1.31% sporting less than 512MB
For what it is worth, the Steam Hardware Survey is great for getting a feel for what people who run steam-based games have, which in many ways reflects Windows Geekdom..
As of May, 2009..
512..999 MB : 7.32%
1 GB : 17.87%
2 GB : 36.04%
3 GB : 26.02%
4 GB : 8.09%
5+ GB : 3.34%
"His name was James Damore."
...I don't.
I have five machines ranging from 4 to 12 GB. I also don't keep applications open long enough for "degradation" to play a role; closing an app gives the OS a chance to play memory organizer just as surely as rebooting a machine (sorry *nix fanboys who brag about all of your oh-so-important 'uptime' when rebooting takes, at worst, a few minutes) gives it a fresh pallette.
I don't CARE about memory usage. Just isn't on my radar, anywhere.
No gods, no demons, and no masters. Secular Humanism!
Yes. I see them too. They arrived right after they fixed the white-on-white comment titles.
You can work around the issue in the same way as with the previous bug: click the "Change" button on top of the comments.
-dZ.
Carol vs. Ghost
Neither would be correct in this case, as they are only including a very small sub-set of the browsers out there and not offering enough context in the title. "Et al" (and others) and "et cetera" (and the rest) both imply the an entire set; the former for proper names, while the latter is for generic lists. The intention is to shorten the list, not create ambiguity.
It would have been more accurate to include the full list, or shorten it with "among others". If the full list of browsers was already understood by context, then using "et al" would have suffice. However, the title does not give enough context for this and therefore implies all browsers. It is the same as saying "Chrome, Firefox and the rest." The rest of what? of all browsers?
-dZ.
Carol vs. Ghost
I got 12GB... so who cares? :D oh wait, I use Opera. :]
I haven't used Chrome on any platform yet, so I cannot speak for it.
Firefox has usually been around 100 Mb for me on XP, which I consider bloated, but I'm aware that resource efficiency isn't important to many of the rest of you, these days. It seems to average at about half that on FreeBSD, but is still the most memory-intensive application I use on a daily basis. Still, for GUI web browsing, I can't complain, so I'm not.
I'm not passionately in love with Firefox, but I don't hate it either; it serves its' purpose and I am content with it. It does what I need, doesn't crash unless there's a problem with a page, and does its' job in a relatively efficient manner. I suspect that my lack of feeling toward it either way is actually due to its' transparency; it stays out of the way to the point where I barely notice it at all, and lets me focus on web content instead, so people would probably tell me that that is a good reason to actively love it.
I would not, however, like to go back to using Firefox without Vimperator at this point. I have heard even one Vim enthusiast express dislike for Vimperator, but I actually consider it probably the single most meaningful user interface upgrade that I have found since Ratpoison; the two complement each other exceptionally well.
leaving any browser open all day long makes my weezy thinkpad x22 essentially freeze after some 16 hours, even if i'm barely using the box (it's durational more than usage based). however unlike what the author experienced chrome causes the least issues and opera the most for me, with firefox right behind opera.
it's a problem since opera is my favorite browser and the stripped down x22 my favorite laptop. luckily it only happens at the end of these long stretches. if i reboot after eight ours it's fine. simply using any browser no matter how intensively for just a few hours is not enough for any memory leakage to become apparent with my setup.
- js.
Its worth more than guessing.
"His name was James Damore."
Ran the same FF and Opera browser setup, and Opera beats the pants off of FF. Don't forget, FF has the worst of the Javascript performance both speed wise and the fact memory usage shoots above Opera and Chrome.
I don't quite understand everyone's aversion to applications using memory. I mean--I'd much rather my applications take the time to use the memory I have, with all 4.5GB/sec of performance on sustained reads than my hard drive which is roughly about 3% of that speed on good parts of the drive structure with RAID0.
Application performance should never be about how much ram it uses, but how it uses it. I'm all for applications being efficient, but if it wants a bunch of ram to make things a bit faster--by all means, I've got 8G in my system, have at it.
This is one of the primary reasons I like Superfetch in Windows Vista/7--because it utilizes ram for application and data prefetching. What better way to use the ram than have the most frequently used programs and information cached and readily available at super high speeds?
I wish some of my applications used more ram (see: WoW) just to improve visible performance (I'd rather have a higher upfront load time than the loading/performance drops mid-game).
I see it too. Real professional that they make these insufficiently-tested (or untested) changes on the live site instead of a test box.
It's merely an annoyance, but still.
Hail Eris, full of mischief...
E pluribus sanguinem
Our five-year old laptops typically run XP with 512MB. They're obsolete, yes, but a lot of smaller companies are like mine, and have to squeeze nickels, and in this economic climate, we're not getting new hardware or even new RAM in the next year. Running IE8 is deadly on these machines.
Wouldn't it be great if there were a way to make security convenient? Is there anything out there that monitors the type of action being taken and only prompts for credentials when the action looks suspicious? I know that if I authenticate on my linux boxes I won't be asked for my password again if I do something else in a short period of time. It's smart enough to know that if I just typed in my password 10 seconds ago, there's no need to do it again. (Which is a potential hole if there was a program running as the user that monitor requests for passwords and then executed the "bad" code immediately afterwards.)
If there were a way for the OS to monitor my actions and know that if I go to Add/Remove Programs and try to install something, I don't need to be asked for my password. But if the install is automatic from a script or web pages, then prompt.
AV programs use heuristics to determine things that might be viruses, could the os learn or take an intelligent guess (erring on the side of security) as to whether or not an action is really initiated by the user?
After all, if I initiate something, I'm just going to put my password in anyway. No reason to prompt.
It does this in Safari 4 as well.
I was able to get rid of this by going to by Slashdot account preferences and selecting "Classic index" under Layout.
it seems to me that memory usage is far less important that CPU usage. I mean if you spike out that processor, then your computer is at a fucking standstill. RAM is cheap, easy to upgrade, and can also be paged out to your hard drive. it is like putting a RAM upgrade in a Celeron. Yes it will *kinda* help with multitasking, but it will still be slow because the processor is holding it back. Chrome still has all of them beat in my eyes as far as speed is concerned.
*plays the Apogee theme song music*
Yes, you did used to be able to do everything you described in 256MB of RAM. But to attribute the biggest increases in web browser memory usage to programmer laziness is to ignore a drastic change in the way we (and by we, I mean the general internet-using public) use web browsers. It's no longer enough to display static web pages. Web applications are mainstream, JavaScript and Flash are practically inescapable.
I was curious, so I just checked memory usage of a web browser (Firefox 3) and an office app (Word 2007). Total memory usage, with four tabs open to fairly intensive sites (slashdot, ars technica, gmail, facebook) and a 10-page document open in Word? 150MB. I do almost all of my web browsing and general computing on a computer with a 1.8GHz Celeron processor and 1GB of RAM. The P4 system you described should be doing just fine.
That's pathetic.
This is my sig.
"My experience of Firefox is over the course use for a week it becomes the biggest resource consumer on my machine and needs to be periodically shutdown"
You actually ran XP for a whole week without rebooting ?
Reducing memory usage - Firefox
In the early days, more RAM meant that you could cache some frequently used information in memory instead of recomputing it or loading it on demand. But there's a diminishing return. Nowadays, it's usually faster to recompute than read it all back from RAM...
That's not quite right. There is a trade-off between speed and memory usage in many cases, but nowadays we have what we consider to be slow and"bloated" software not because the software is storing in memory what it should compute each time, but rather because of the large number of abstractions used in some modern software. Each level of abstraction increases overhead (essentially wasted CPU cycles) as well as overall memory use. Thus we see that new features and required resources increase at some above-linear rate.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
27.8Mb here...
You should see another process floating out there. There's a root chrome process and another for the tab. Either that I have a zombie.
This is my sig.
Ok, 50 megs then. But most of that memory is probably shared,so I'd guess its actually quite a bit less.
Average gamer rigs are far above average desktops.
(founded 95,000,000 yrs ago, very space opera)
> Compare recomputing something, where you never have to leave L1 cache,
Only if the data that the result depends on fits in that cache...
For example, Gecko saw a noticeably performance increase from caching the intrinsic preferred and min width for CSS blocks. Yes, it increased the memory use per block by 8 bytes. But recomputing not only used the CPU a good bit but also depended on the values of dozens of CSS properties for all descendants of the block.. which had to be read from memory.
Also, caching can sometimes change the algorithmic complexity of a problem (e.g. compare computing Fibonacci numbers via recursion with and without memoization of the results).
Buy yes, there are some limited cases where recomputing is better than caching; cases when there's a 1-1 dependency between the data you already have and the data you'd like to have are probably in this category.
Currently Gecko does #4 from your list for a bit (to allow fast back in common cases), falling back on #1 once evicted from that cache (which happens after the page is far enough back in your session history or once 30 minutes have passed, whichever happens first). "Far enough back" is typically 3-7 pages back. Oh, and while it does #4 for DOM and style information, decompressed image data is dropped more aggressively than that. In fact, it's commonly dropped while the page the image is in is still loaded, with decompress happening on draw, if the image really needs to be redrawn. So really, your list should probably be a graph with nodes representing various combinations of memory optimizations; the image data optimization is completely orthogonal to what you do with the DOM and layout information.
> Firefox does the latter,
Not sure what that would mean for a list with 5 elements, but see above for what Firefox actually does.
> Redrawing the page image from the DOM should take only a few milliseconds
If you mean recomputing all the layout information from the DOM and the specified CSS values, then I think you're off by one to two orders of magnitude or so (for typical pages; I'm not talking pathological cases like the HTML5 single-page spec where a full layout pass in any modern browser takes multiple seconds, nor particularly simple pages like the Google front page). Times are in the 50-600ms range for layout of the page on things like top500 pages.
The point is that the single metric of this test, though in a way useful, is not the best way to measure performance.
There's a difficult position: that more is better, on the back of the free work of others.
Maybe the point should be whether this test measured the most useful value given the amount of effort invested in the test, or whether they should have bothered at all, if this was the most they could manage.
From a cost/benefit perspective, I think there's enough value in what was accomplished *despite* these uncertainties. That said, if they could have managed to repeat this test run after yanking out a 2GB memory stick, that would be extremely informative as to how these browsers respond in a reduced memory circumstance, and how much of their memory use under large memory conditions was speculative.
Just last week my commit charge on my XP system at work was in 4GB territory with 3GB of RAM installed. I had ten FF windows scattered over nine desktops. Four of the desktops had Eclipse workspaces open, plus sundry office junk, but none of my big memory hogs, such as R, running large jobs. I don't think memory consumption is a non-factor yet, for small values of yet.
Let's back up for a moment and look at the big picture. I remember, all too vividly, back in the mid 1990s when one of the all-time favourite MS bashing memes was "no matter how large you make the hard drive, the next version of Microsoft 95/98/NT and Office would immediately expand to fill it up." In the minds of many teenage fanboys, the primary virtue of Linux was that it would run well on a 500MB hand-me-down disk drive.
The fact of the matter is the many of those early versions of Windows were highly compressed and curtailed, at great effort, to run well at all. As hard drive capacities increased (along a completely predictable trend line) Microsoft stopped bothering with the suitcase packing tricks, and allowed the software to expand to its natural size, somewhere between 4 and 10 GB. Shock, horror!
In the minds of many fanboys, software bloat makes an appearance on the end-of-civilization top-ten list. For about a year, which didn't stop a lot of people from posting on web discussion pages a very tired meme for years afterwards, as badly dated as rotary phones and bell-bottom pants. Sadly, I had to conclude that MS bashing causes brain rot.
Back to the present. Browser memory consumption is going to follow the same inclined hockey stick. Even with a migration toward Google apps.
Fast forward two years from now, as the economy comes out of the tank, and large build-out of corporate desktops with an 8 GB standard memory install, this discussion will be as quaint as wondering whether the upcoming Windows 2000 will install successfully on a 40GB hard drive.
Earlier this month I priced a 12GB memory kit for a Core i7 system at USD$180 street (name brand). At 12GB, making the jump to a 64-bit OS is a no-brainer, as you're way past the pointer-size penalty.
A much bigger factor in browser performance is how well these browsers exploit the available cores.
For the netbook segment, it boils down to power efficiency: you don't really want to fire up eight cores to render compressed images every time the user presses the page down key, so the major impact of good memory caching will show up less in response time and more in power consumption.
(Footnote concerning FF on multiple desktops. I absolutely *love* the FF FireTitle add-on. Press CTRL-; and it prompts you for a Window name, which becomes visible at the front of the process tab. The downside is that session saver doesn't capture the assigned window names so every time Adobe snafus FF, I have to assign all my window names over again. Nor does my session saver remember my window assignments under my multidesk client. Nor does Adobe remember its own session data, which is utterly incredible considering how often Adobe *deliberately* requires a restart to install patches. What I would give for a Chrome PDF viewer to smarten these guys up.)
Its worth more than guessing.
I'm not convinced it is, actually. My statistics above were from support work my company has done for numerous clients, mostly small/medium enterprises. They present a quite different picture to yours, yet I'd wager the market they're a sample of is a substantially larger one than the market your stats are a sample of; yours are, of course, more reliable for the market segment, as I imagine they're virtually a census of keen windows gamers.
Well as far as enterprise stuff, the choice of browsers is normally based purely on reliability/compatability, not memory usage.
As far as the size of the steam survey.. tens of millions.. over a million concurrent users at any given time of day or night (thats the MIN/LOW figure), and steam games don't exactly have high performance spec requirements (some due, vast majoority don't.) You are right that these arent representative of enterprise machines, but then you are really talking about corporate internanets and so forth and not having a wide navigation profile with hundreds of tabs open, which makes TFA useless.
"His name was James Damore."
Nah, they haven't. It is the corporate bean counters, CEOs, and boards of directors who have no loyalty to Abrash's Zen of Assembly Language; coding for cycles and bytes takes time.
The whole point of making code modular and dependent upon pre-existing "frameworks" - plug'n'play, if you will - was to dispose of those expensive programmers who could craft code in favor of those who could generate code.
Don't need good, tight code, when you can generate bloatware offshore, release it, and then throw hundreds of programmers at bugs post-release and still turn a helluva profit.
And the bean counters and the folks who get paid in stock options and so forth don't give a damn what box the public is running; witness Vista, the computer retailer's friend.
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
And don't forget the mouse gestures!
I'm mousing left handed. It's really a boon to not have to use both hands (or switch hands) to move between tabs, close tabs, open links in new tabs.
*sigh* You know you have issues when mouse gesture software improves your sex life :(
Try this: load a simple html file (no javascript) in ff, open several tabs and load the simple html file in each tab. I am guess that will not crash ff.
For me, it's javascript that kills ff. I am guessing that certain ff just can not handle certain javascript operations. For me, hitting the wrong kind of javascript is like stepping on land-mine, cpu usage is peaked at 100% and I have to kill ff.
[disclaimer: I work for google on chrome]
First off, Firefox is definitely great at keeping memory usage low - better than Chrome. Some on this thread say that firefox has memory leaks and bugs. I don't know about that, I find Firefox is pretty solid. Nonetheless - one advantage Chrome has is that tabs are in separate processes. So, as you close tabs you get to completely flush out all memory from that process. This adds a level of resiliency to chrome you can't match in single process browsers.
Second - thanks to dotnetperls for posting their methodology and their exact test source code! The only question I have is "which memory metric was used?" There is a big difference between "working set private", "working set total", "private bytes", etc.
What is the right metric to use? I use the same metric Vista uses: private working set. You might argue "why not use private bytes"? I agree this seems like a good metric, and it's not a bad one. But, it doesn't reflect user experience.
Why? Because the working set is the amount of memory *not available to other apps*. If other apps can have the memory, then using the bytes is inconsequential. Private bytes does reflect bytes allocated by the process at some point, but the OS is not using physical RAM for those pages right now.
For most applications, there isn't much difference between "private bytes" and "working set private bytes". However, because of Chrome's multi-proc architecture, there is a big difference. The reason is because Chrome intentionally gives memory back to the OS. For instance, on my current instance of Chrome, I'm using 16 tabs. The sum of the private bytes is 514408. The sum of the private working set bytes is 275040, nearly half of the private bytes number. This is on a machine with 8GB of RAM, so there is plenty of memory to go around. But if some other app wants the memory, Chrome gave it back to the OS and will suffer the page faults to get it back. Since Chrome has given it back to the OS (and has volunteered to take the performance consequences of getting it back), I don't think it should be counted as Chrome usage. Others may disagree. But Windows uses working set as the primary metric for all applications the OS folks agree that working set is the right way to account for memory usage.
Single process browsers have a hard time giving memory back, because they can't differentiate which pages are accounted to unused, background tabs and which pages are accounted to the active, in-use tabs.
One last note: If you have a version of chromium, you can run it using --single-process. I ran the dotnetperls test in this mode, and then Chrome and Firefox are pretty close in memory usage. Firefox still wins. But most of this memory use is due to the explicit tradeoff to use multiple processes rather than use minimalist memory.