My fellow Antistress argued that I should be going back from Chromium to Firefox today. I replied, “Only when it starts up in less than 3 seconds and frees my goddamn memory when closing tabs”. He then replied with the following statement:
firefox a la meilleure gestion de la mémoire tous navigateurs confondus (cf tests unanimes sur la toile)
Which roughly translates to:
[Firefox 4] has the best memory management, better than all other web browsers. See the unanimous benchmarks on the web [citation needed], you fascist pig.
Being a good sportsman, I could not turn down the challenge. I had to see for myself, so I downloaded the Firefox 4 Beta 6 and spent two hours comparing it to Chromium 6.0.472.53 (rev 57914, the version available in Ubuntu 10.04’s repositories).
Some boring notes/disclaimers
- I am not affiliated in any way with either the Chromium or Firefox projects.
- To test cold starts, I ran the following command to empty the kernel’s disk caches: sync && sync && echo 3 > /proc/sys/vm/drop_caches
- I tested startup times on a powerful desktop computer (Dell Inspiron 530n) and a netbook with a cheap solid state drive (Dell Mini 9). I used only the desktop computer for testing memory usage. All tests were run on Ubuntu 10.04 LTS with Linux 2.6.32-24 generic PAE.
- All tests were run multiple times to make sure measurements were valid. There is of course some margin of error, but it is slight.
- I don’t claim to be a memory expert, but I tried to do the tests in the most rigorous and fair way with the means available to me (I even gave Firefox some slight advantages here: blank home page, under-reported memory usage, etc.).
- Due to the PITA that is measuring and calculating memory usage over multiple processes, in Chromium I use about:memory. I look at the “Private” column.
- The about:memory tab uses memory (around 6 Mib on average), so it is substracted from results.
- I usually wait a few minutes before measurements because both browsers need a bit of time to “stabilize”.
Startup benchmarks
| Cold start | Warm start | Mini 9 Cold start | Mini 9 Warm start | |
| Firefox 4 beta 6 | 7,35 | 1,69 | 4,61 | 2,92 |
| Chromium 6 (rev 57914) | 6,99 | 0,43 | 2,28 | 1,48 |
Obligatory pretty Gnumeric charts:
Some interesting things to note here: on the netbook, Firefox’s cold start performance improves, while both Chromium and Firefox’s warm start performance is lower than on the desktop. I believe this is due to the Atom N270 processor (we’re comparing it to a Core2Quad, you know…). This would lead me to think that Firefox’s startup is more I/O-bound, and Chromium is mainly CPU-bound (the system monitor applet does indicate a big CPU spike). It would be fun to try this on a Core2Quad with a SSD drive.
All in all, Firefox’s startup time has improved considerably these days (I can’t start 3.6.10 on my netbook in less than 18 seconds). It would fit the “less than 3 seconds” startup requirement. Not as fast as Chromium, but “good enough”. I guess we can pat Firefox on the back.
Memory usage
Let me clarify something: I care about “per-tab” memory usage, but a lot less than what happens after the tab has been closed. I don’t care if you consider it a feature, when I close a page, I want my memory back. Now. Otherwise, I will not be able to use it for more than a few hours/days without having to restart the whole application to free my memory. This is what made me leave Firefox. It is a big deal. It trumps everything else (after all, startup time doesn’t matter that much if you don’t have to restart the app to begin with).
Here, I ran two tests: a “gentle” test using Ubuntu’s website, and a “torture” test with Microsoft’s website.
The gentle test (measure memory at each step):
- Startup (blank page)
- Load ubuntu.com
- Open ubuntu.com’s nine toplevel links in new tabs
- Close the 9 tabs
- With the remaining tab, go to scholar.google.ca
| Startup (blank) | +ubuntu.com | +9 tabs | -9 tabs | ubuntu.com –> scholar.google.ca | |
| Firefox 4 beta 6 | 43,9 | 113 | 202,9 | 171,8 | 162,7 |
| Chromium 6 (rev 57914) | 72 | 104 | 174 | 152 | 91 |
We can see that Chromium uses more memory on startup, but consistently beats Firefox afterwards, and basically comes back to the baseline level when you close the 9 tabs. But isn’t this test a bit too convenient? Let’s be a bit more cruel to Chromium and ask the kings of bloat (Microsoft). Furthermore, let’s throw in what Chromium thinks is Firefox’s memory usage…
The torture test (measure memory at each step)
- Startup (blank page)
- Load microsoft.com
- Open all the links in the “Products” menu and the “Windows” toplevel menus, in new tabs
- Close the 27 tabs
- With the remaining tab, go to scholar.google.ca
| Startup (blank) | +microsoft.com | +27 tabs | -27 tabs | microsoft.com –> scholar.google.ca | |
| Firefox 4 beta 6 | 44,3 | 128,6 | 367 | 239 | 235 |
| Firefox 4 beta 6 (according to Chromium) | 61 | 142 | 394 | 262 | 261 |
| Chromium 6 (rev 57914) | 73 | 108 | 508 | 153 | 91 |
Now, that’s quite interesting:
- Chromium still requires more memory on startup.
- Chromium eats more memory with large amounts of tabs; but if I recall correctly, this has been widely known for years: its 1 tab = 1 process architecture means that each tab has an additional memory overhead.
- Chromium still destroys Firefox in terms of fully releasing the memory when you close tabs. It basically goes back to its baseline level, while Firefox sits at four times its baseline.
- Interestingly enough, Chromium over-reports Firefox’s memory usage (vs gnome-system-monitor). Logically, the inverse could be true: it is possible that g-s-m over-reports Chromium’s memory usage. I am giving Firefox an advantage and penalizing Chromium here.
Additional observations:
- Firefox takes a long time before freeing any significant amount memory. I had to wait 2-10 minutes. I guess it’s a feature and I’m not using Firefox as intended.
- Firefox’s GUI gets sluggish when you quickly open (or close) tabs. Chromium doesn’t suffer from this. This is perceptual and is somewhat outside the scope of my benchmarks.
Conclusion
Firefox has improved a lot, but it still fails at giving me back all my memory when I close tabs. I cannot trust this. Feel free to tell me that my understanding of “how RAM usage should work” is completely wrong. I kind-of hope I’m very wrong.
Comments
25 responses to “Free my memory5 min read”
I think what you’re seeing is that Firefox keep the last few pages you’ve been too in memory in case you click the back button (or click ctrl-shift-T). And I also believe that Firefox will free that memory if the system is experiencing memory pressure.
Interesting numbers, could you extend your numbers with an larger number of tabs (important would be around 150) ? This is precisely the reason I stick with Firefox, I do have a lot of tabs open, and Chrome just eats much much more memory (around 30MB per tab). I do agree though that JS performance is better with Chrome.
Firefox holds the (now unused) memory because if you opened 9 tabs once you will probably do it again and it will need the memory so giving it back to OS is just an overhead. It is NOT a leak as this memory will be reused if you open 9 new tabs with different content. If opening few new tab after closing previous tabs increases the total memory usage then it’s a memory leak as the memory is not being reused.
Since the way that you want Firefox to operate is different from the default, I’m curious to know if tweaking the browser.sessionhistory values to your use case helps with your particular benchmark? (Perhaps try setting both values to 0.)
Perhaps he’s referring to this old study in which Firefox beats the competition:
http://arstechnica.com/open-source/news/2008/03/firefox-3-goes-on-a-diet-eats-less-memory-than-ie-and-opera.ars
“fascist pig” ? i wouldn’t say you’re a pig 😉
I must admit that your method looks very rigorous.
But maybe we shouldn’t trust appearances… i don’t think that you indicators are 100% discerning actually.
What is a good memory management to me ?
Good memory management means no memory leak to start. It means that if open several tabs in my browser, memory consumption will not grow as time passes by.
What a pity : you didn’t test that whereas it would have match you’re own model (“Otherwise, I will not be able to use it for more than a few hours/days without having to restart the whole application to free my memory”). I wander if Chromium memory use would increase as time passes by with a fix number of tabs ? I’m pretty sure that Firefox has better memory management (i know : you will answer “citation needed” but i expect you to drive the test 🙂
Moreover, looking yours tests, i would draw a different conclusion : eating 508 Mio (Chromium) instead of 367 (Firefox) on a Dell Mini 9 – which comes with only 1 Gio RAM – is quite penalizing. I wouldn’t call that “good memory management” either for such a netbook.
PS : sorry for my not so good english
PS again : thank you Ernst for the link
Still PS : startup time should reduce more shortly see https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements & http://blog.mozilla.com/tglek/ and especially for Linux : https://bugzilla.mozilla.org/show_bug.cgi?id=559964
Last PS : about memory management, here is another interesting initiative from Mozilla : http://mozillalinks.org/wp/2010/09/firefox-4-now-with-optimized-session-restore/
I have an Intel SSD. X-25M, second gen, TRIM firmware. Chromium starts instantly. FF still takes a couple seconds. Not acceptable. I’ve moved my whole family to chromium, and I think it should replace FF as the default browser in Ubuntu.
The Firefox 4.0 betas have more known memory leaks than 3.6. Just make sure you test again when the final is released.
Also Firefox has a back-forward cache that make page loads really fast for going back and forwards(faster than chrome in my experience). You can control how memory hungry this cache is through about:config. You can Google the exact instructions.
Beta 7 *should* further improve startup times bit more too.
A real memory leak is when memory is not freed when the program is closed., or if memory use grows independently of what the program is being asked to do.
People may like or dislike FF’s memory/cache management, but it hasn’t had a real leak in a long time.
I don’t usually have slow UI in FF or Mozilla unless I have upwards of 100 tabs open or I have a lot of JS or Flash going on.
And I will never, ever understand people that insist on opening and closing their browser all day long. My average uptime for Mozilla is probably 24-48 hours and it would be a lot longer (probably 5-7 days, or more) if I didn’t run nightlies that always bug you to update them (and Debian Unstable, which needs a fair amount of rebooting after updates to the kernel or libc).
« A real memory leak is when memory is not freed when the program is closed., or if memory use grows independently of what the program is being asked to do. »
I agree.
I don’t really understand people who are complaining to see their memory be used. If you have 2Gio of free memory, why you browser shouldn’t use it ? What’s important is that the browser frees the memory when other applications need it, isn’t it ?
I suppose that if Firefox keeps some memory after closing a tab, it is used to restaure tab ( you know, Ctrl+Shift+T ) and it frees the memory after a while, am I wrong ?
There are few things what should be in mind when doing memory tests.
1. If computer has little the RAM, then it is wise that all the application programs does not use it more than what is needed. Forcing a application program to use a virtual memory is not good thing. I have a laptop with 512MB of RAM. That is very little on today, usually 2-4 times less than what typical laptos has. Even my netbook has 2GB. The computer usability goes down when I run out of RAM and virtual memory is started to be used so swapping happens. At that point, the old 1.7Ghz Pentium M can not handle todays multimedia (Videos, WWW-sites with Flash and so on) if one application program (or suddenly one system program) starts eating RAM more than I do have.
And usually that point means I need to kill the web browser. As it is the only one what actually eats it.
2. If people buy RAM to their computers, do not let it to sit down empty!
Doesn’t anyone anymore remember the Windows 9x times where Windows users bought the extra 32-64MB RAM to their computer so they had 64-128MB? And then they whined how the RAM was 30% used and not just 20% as after reboot? And then when they tried or made longer timed operating system swtich from DOS (9x series) -> Linux, many whined about how Linux is so terrible OS because it does not empty the RAM after application programs were closed!
There were so many newsgroup posts and forum posts (that time rare) asking about how to compile the Linux OS so it does not eat RAM.
At that point, the same explenation was (question actually), “why did you bought the extra RAM if you are not going to use it?”
People were learn that RAM needs to be empty. That high RAM usage is not good at all. And when they asked free -m or top about how much they have free RAM, they were terrified when it was 98% used all the time after short time of use. They immedenitelly pressed the “PANIC!” -button as something is wrong.
And now same thing is going right now here.
3. How does Chrome/Chromium or Firefox work in actuall tests?
Start the browser program, open the +20 tabs from all different sites, not just from one site (like 19 tabs from canonicals site). Watch the RAM usage.
Then close the tabs and check the RAM usage. (This is what you have now done).
Now, do the correct tests:
Check how much there was free RAM after you had few tabs open (2-3 tabs, not the 20 tabs) and what was the virtual memory amount (swap).
Then fill the RAM full of random data from /dev/random by few different blocks.
Check the memory consumption again. Did web browser free the memory or did it kept it?
It is naive to want a application program (or system program, system service and so on) to have as less RAM used than just possible, when you do not have RAM full.
It does not make computer slower, it does not consume more power. Only then when the RAM is filled by running application programs that newly started programs can not get reserve it, cause slow downs. And usually at that point, the operating systems like Linux (kernel) are so smart that they flush the programs to swap what are not in the run at that time but idling. Like if you have a painting program in one virtual desktop and document writer in other. You use web browser to search sources and you paste them to document writer and then you start a 3D application to render scene and same time you continue to search sources and adding them to the document, the Linux OS (=kernel) will place the painting program to swap before it does place the running programs to the swap.
Then there comes the small slowdown when you return to the painting program as it is re-read from the swap to RAM and a another application program is written to virtual memory from RAM.
————-Bottom Line——————
I do not care how much my current used Application program is using as long as:
1. It does not fill the RAM so it starts swapping (if there is memory leak, it is bad thing for the application itself. But OS will free it when the process is closed, and others process ask memory afterwards. If not OS is not working wrong way and it does not free it to others when needed. But the OS can not detect is the application program leaking memory or is the demand real. So leak is very serious problem as it can eat all RAM and virtual memory by doing so).
2. My used application programs are working well without them being a slow and some idling application program being fast.
3. I have free RAM to actually use.
Fri13: any memory that is not used by applications can be used as disk cache. And that _really_ makes a difference. Try running “echo 3 > /proc/sys/vm/drop_caches” as root to clear disk caches, and then try using your system. Usually this makes it feels slow as molasses until the important data has been re-read from hard disk platters and put into cache again. Now imagine using such a slow system all the time because FF keeps hogging the memory “for performance reasons” so that there is no memory available for disk cache. That’s what I experience when I use FF extensively, and it sucks.
This is worsened if you eg. run large compiles on your system. Building our C++ application accesses some hundred MB of data from disk; if this is cache, compilation flies; if it’s not cached, compilation takes about 5 times as long, and you can see the high I/O wait percentage in top.
Another point (where I admittedly didn’t do much research) is that FF appears to hold onto lots of memory so that it is not swapped out. When using Konqueror I can usually get lots of its memory moved to swap when leaving the window unused for a while. FF however always requires lots of memory in physical RAM even if the browser is not used. It might be interesting to see if this is really the case, and if so what might cause this.
“Now imagine using such a slow system all the time because FF keeps hogging the memory “for performance reasons” so that there is no memory available for disk cache. That’s what I experience when I use FF extensively, and it sucks.”
When your RAM is full, does Firefox clear the RAM as Linux OS (=kernel) starts checking what app is not used and starting to move it from RAM to Swap?
Did you fill your RAM with random data to get back to the status what was with few tabs, after you closed all other tabs?
> I can’t start 3.6.10 on my netbook in less than 18 seconds
You’ve got other issues, I’d have to say. Perhaps Chrome is bundling its libraries or is somehow able to load them faster than your default OS libraries? Because 18 seconds is absurd, even for a *buntu.
Interesting perspectives. I did think about the “Firefox keeps pages in memory so you can reopen your closed tabs instantly, you insensitive clod!” hypothesis. However, if it is true, it is stupid.
I care about my memory being freed, not about being able to “instantly” reopen a tab I *decided with 80% certainty* to close; if I made a mistake and want to reopen that tab, I don’t *mind* if it takes a second or more; I’d expect it to reload (unless, maybe, it was a form with unsubmitted data). If you find yourself constantly reopening closed tabs, you need to control your impulses when closing tabs 🙂
Olivier’s comments about Firefox hogging memory and penalizing other apps rings true to me (from my past experiences).
I haven’t done a test with 200 tabs because I was lazy and it gets confusing quickly (ie: are you *sure* you opened the exact same amount of tabs?). And I’m sure, extrapolating from my 28 tabs results, that Chromium would use more ram in its “peak usage”. But when I close them all, it would free it entirely.
I know that on Linux, using the RAM for caches is a good thing. But Firefox shouldn’t be eating the entire cake.
Here’s an additional question to entertain: how can you be sure there is no memory being wasted (what I naïvely call “memory leaks”) when you can’t be sure that all the RAM was freed on tab close? How do you differentiate between normal and abnormal behavior when there is no clear cutoff line (ie going back to zero)?
Just a quick question: Could we say that “tab-per-process” of Chromium leaves the job of returning memory to the OS? If yes, we could see subtantial differences between OSs for the same tests.
There are numerous prefs in about:config you can tweak to control how aggressively Firefox will reclaim memory, and how aggressive it is about dropping uncompressed copies of images (it keeps the compressed copy separately, and drops the uncompressed one more aggressively, you can make it more aggressive still)
ways you can make FF more aggressive:
possibly setting image.mem.decodeondraw to true will help reduce Firefox’s per-tab memory usage further (this will cause it not to de-compress pngs/jpgs/etc until it actually needs to show you the image, eg if it’s on the page but not currently visible it will not bother decoding, Note there is a reason this currently off by default…)
decrease image.mem.min_discard_timeout_ms (firefox will drop images faster, IIRC this refers to how long it waits before it decides it no longer needs the uncompressed version)
These aren’t the best things you can do to make FF more aggressive, just the ones I could remember enough about to google quickly, there are, of course, others, but you’ll have to google for them (and be careful the advise you find is still relevant)
There are of course other things you can do, but next time you test make sure you wait a few seconds before taking your memory readings since Firefox may wait to see if it still needs some things (like images, eg you have lots of tabs open on the same site, you’ll probably have at least some images showing up in every one of those tabs), or perhaps it just waits for the GC to collect stuff for it sometimes.
Basically make sure you’re really doing a fair comparison, give Firefox a chance to let it’s internal reclaim get some stuff.
Also a much more fair test is open several tabs, close most of them, open several more, close, and so on a bunch of times, wait say 10 seconds, then measure. In the case where you’re not comparing long-term stuff Chrome has a large advantage because of the separate address space, however it’s likely that this advantage is MUCH smaller over the long haul, and if Firefox actually is free of leaks it really ought to be able to do better than Chrome in terms of overall RSS, while you’re actually using it.
There is another way your test is unfair to Firefox, when Chrome exits a process the kernel knows immediately that a given page can be discarded, with Firefox, it will NOT discard any heap pages until something wants them… so if Firefox is all you’re running it’s RSS size will not shrink much since nothing else is making demands for memory, THIS IS A GOOD THING.
tl;dr you can make Firefox reclaim more aggressively and comparing memory use is HARD
Also look at BarTab, it lets you keep tabs open without having the actual content loaded.
Also setting browser.sessionhistory.max_total_viewers to 0 should reduce Firefox’s per-tab memory usage (if you actually, ya know do some navigation in that tab anyway) however this would be cheating since IIRC WebKit has a similar mechanism by which it keeps a couple things from your back/foward stuff loaded and ready. This has nothing to do with how long it takes to reclaim stuff after you close a tab however.
If you aren’t either instrumenting Firefox, or at least using it’s about memory you ARE BEING VERY UNFAIR. Since as a I said before the kernel has no way of knowing that a given page of heap is no longer needed after you close a tab so it will continue to occupy physical memory until such time as something kicks it out, this has nothing to do with how good Firefox is at figuring out when it’s done with some memory, in Chrome the closing of the tab and the kernel knowing it’s OK to throw that page out ARE the same thing… Chrome’s case is harder for the kernel since next time you open a tab it actually has to do some work, whereas with Firefox malloc will just return a pointer to the memory, and then the only thing the kernel will not be involved and less work gets done.
As an aside, Firefox is likely ending up with some mmap allocations for big things (like say images), and that address space is obviously free’d, the pages returned, and the RSS size decreased.
I don’t know if Chrome’s about:memory actually shows you RSS or not (I don’t think it does, since it doesn’t actually have a 1-1 process-tab correspondence, it’s one-to-many, yet it still shows per tab breakdowns of mem usage, so this would under count actual impact on RSS, and so be VERY unfair to Firefox)
See since Firefox just plain uses less memory per tab if you’re actually under some kind of pressure it’ll be better.
A slightly more fair test might be open 9 tabs, measure, close them all, open the same 9 tabs, measure: compare, this will give you a better idea of how much Firefox is actually wasting.
I have to give Chrome the edge fundamentally when it comes to reclaiming memory because of the multi-process model. On Linux (and other Unixes), having a process shrink its memory usage can be tricky. Generally, free()ing what you malloc() isn’t sufficient, unless you’re malloc()ing sufficiently large chunks (in which case mmap would be used).
For smaller chunks (less than MMAP_THRESHOLD), brk() is used instead, which grows the process’s heap size. Freeing allocated memory within (as opposed to from the end) of the heap space will cause memory fragmentation and prevent the heap size from shrinking.
So, Firefox must specifically deal with this issue (I’m not sure if it is), whereas Chrome gets a solution for free (at least at the per-tab level) by virtue of using multiple processes.
@spudd86:
Alas, this is not mom-proof. I’m benchmarking the default behavior of both apps, not behavior of “app with foo-bar patch and tweak xyz”. It’s not a video encoder contest!
I did. As I mentionned, I waited several *minutes* to let Firefox stabilize before taking measurements. In my latest round of tests (below), I waited at least 7 minutes.
I don’t understand how this would be any different or more fair, really; it’s just a different ratio of open/closed tabs. And I think that I honestly pointed out that Chromium’s peak memory usage is *MUCH* bigger than Firefox’s (this is FF’s strength). As I said, the metric I am rather interested in is getting all my memory back. I think there are too many confounding variables if you do a test such as “open 60 tabs, close 30, open 30, close 30, open 30, wait 10 minutes, measure”. Not only that, but it is a royal pain in the ass to do without screwing up (and I spent a decent amount of free time measuring this). You’re welcome to measure this and show me how wrong I am though 🙂
In short: I’m still not convinced of the soundness of measuring in such a “hybrid” approach; seems like potential sample contamination (but I may be wrong here).
What do you mean by instrumenting? I’m unfamiliar with that term.
As for using about:memory: there, here are the same numbers with the same “torture test” with about:memory from firefox (I didn’t know it existed, how silly of me).
Firefox 4 beta 6 (about:memory, mapped): 44, 130, 387, 380, 379
Firefox 4 beta 6 (about:memory, in use): 39, 104, 334, 215, 215
There is probably some variance due to the fact that this test has been run 2 days later, but I can’t just keep doing this over and over again for every possible scenario. I’m not a kernel architect, I’m a user, and everybody (every app) seems to have a different measurement/interpretation of what memory usage is.
Chromium reports RSS memory usage. If you hover above the (?) icon in about:memory, it says that “Private” is “Resident memory size that is not shared with any other process. This is the best indicator of browser memory resource usage”.
On that note, need I point out that gnome-system-monitor (my initial measurement tool) agrees with Chromium’s about:memory’s measurements of Firefox’s memory? They have the same curve slope. The only difference is the position on the Y axis on the graphs (g-s-m being consistently a few Mib lower). They seem to calculate the same thing, and I trust g-s-m (don’t remember the link that explains what the Memory column calculates).
Done. +27 tabs, -27 tabs, +9 tabs, -9 tabs. Same phenomenon observed.
But then I’ll stop here with two possible conclusions/hypotheses:
– It still truly hogs memory in a way that displeases me but nobody wants to admit it, or
– Everything I can perceptually see and feel is wrong, I should not question Firefox’s perfect memory usage, and should entrust it entirely with my system’s resources (and I’m stupid for even starting this debate 😉
And it’s not like Chromium destroyed Firefox on all metrics here, it did so on *one* aspect of memory usage. Somehow I don’t think I treated Firefox unfairly, but if I did, someone should fork my blog post and do it 100% properly to everybody’s satisfaction (test multiple times with 10 tabs, 30 tabs, 100 tabs, 300 tabs; with mixed opening/closing tabs; with varied measurement tools; on multiple websites; on multiple machines; with measured impact on other processes on the system; etc.).
Well my main point is that RSS is somewhat unfair to Firefox because it will not decrease until something else wants the pages, even if Firefox is no longer using them.
The reason I suggested doing multiple open/close cycles is because if FF memory usage grows (significantly) with each cycle it’s leaking.
I think perhaps a better test might be open/close a bunch of tabs (say 5ish groups of 9-20 tabs) then measure the usage with final group still open (after waiting for memory usage to stabilize)
Also both browsers have ways to automate exactly this kind of thing…
Without digging deep into the different browsers and figuring out the things the developers of them us for their test suits you can do:
Firefox has the open all bookmarks in a certain folder at once as tabs, Chrome has something similar, so for your test you can just make a folder for each set of tabs you want to open, then you know for sure you opened the same ones every time. (You can even use explicit import/export to make sure you use exactly the same bookmarks for both browsers)
some more information about Firefox caches
“Tuned our caches
Firefox uses various in-memory caches to keep performance up including a memory cache for images, a back/forward cache to speed up back and forward navigation, a font cache to improve text rendering speed, and others. We’ve taken a look at how much they cache and how long they cache it for. In many cases we’ve added expiration policies to our caches which give performance benefits in the most important cases, but don’t eat up memory forever.
We now expire cached documents in the back/forward cache after 30 minutes since you likely won’t be going back to them anytime soon. We have timer based font caches as well as caches of computed text metrics that are very short lived.”
and
“Adjusted how we store image data
Another big change we’ve made in Firefox 3 is improving how we keep image data around.
Images on the web come in a compressed format (GIF, JPEG, PNG, etc). When we load images we uncompress them and keep the full uncompressed image in memory. In Firefox 2 we would keep these around even if the image is just sitting around on a tab that you haven’t looked at in hours. In Firefox 3, thanks to some work by Federico Mena-Quintero (of GNOME fame), we now throw away the uncompressed data after it hasn’t been used for a short while. Not only does this affect images that are on pages in background tabs but also ones that are in the memory cache that might not be attached to a document. This results in pretty dramatic memory reduction for images that aren’t on the page you’re actively looking at. If you have a 100KB JPEG image which uncompress to several megabytes, you won’t be charged with the uncompressed size when you’re not viewing it.
Another fantastic change from Alfred Kayser changed the way we store animated GIFs so that they take up a lot less memory. We now store the animated frames as 8bit data along with a palette rather than storing them as 32 bits per pixel. This savings can be huge for large animations. One extreme example from the bug showed us drop from using 368MB down to 108MB — savings of 260MB!”
http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/
If you close 27 tabs it’s sure you will close your browser either so it isn’t a big issue if FF don’t give back all used memory.
I like Chromium a lot -I love it, actually- but at the speed it eats my RAM (4gb on a 2.66 QuadCore running Arch Linux x64 + KDE SC 4.5.2) I still *have* to use FF when launching lots of tabs, name it 40+, because Chromium *WILL* f*ck-up my system…
Quoting this post: http://superuser.com/questions/86285/firefox-tab-recycling
Here’s an article discussing some of the about:config tweaks you can use that are related to heavy tabbed browsing.
1. Go to about:config in Firefox.
2. Type in “session” in the “Filter” box.
3. Edit browser.sessionhistory.max_entries – this is the number of pages stored in the history of your browsing session. Basically these are pages that can be reached using your Back and Forward buttons. The default is 50 – I reduced it to 20.
4. Edit browser.sessionhistory.max_total_viewers – this is the number of pages that are stored in RAM so that they aren’t re-processed by Firefox’s rendering engine. This is what allows you to go Back to a page in Firefox and have it load almost instantaneously. The number of pages stored actually depends on the amount of RAM on your machine (see this). I reduced this to 4 (I have 2GB RAM).
5. Edit browser.sessionstore.max_tabs_undo – the number of tabs you can restore after closing them (you can do this with Ctrl/Cmd-Shift-T). The default of 10 is more than I really need, so I reduced it to 3 tabs.
6. Edit browser.sessionstore.interval – Firefox saves your session after every 10 seconds by default. I changed this to a more conservative 30000 milliseconds.