tl;dr
Firefox 7 uses less memory than Firefox 6 (and 5 and 4): often 20% to 30% less, and sometimes as much as 50% less. In particular, Firefox 7’s memory usage will stay steady if you leave it running overnight, and it will free up more memory when you close many tabs.
This means that Firefox 7 is faster (sometimes drastically so) and less likely to crash, particularly if you have many websites open at once and/or keep Firefox running for a long time between restarts.
Background
Firefox has a reputation for being a memory hog, and the efficiency with which it uses memory has varied over the years. For example, Firefox 2 was quite bad, but Firefox 3, 3.5 and 3.6 were substantially better. But Firefox 4 regressed again, partly due to a large number of new features (not all of which were maximally efficient in their first iteration), and partly due to some over-aggressive tuning of heuristics relating to JavaScript garbage collection and image decoding.
As a result, Mozilla engineers started an effort called MemShrink, the aim of which is to improve Firefox’s speed and stability by reducing its memory usage.Β A great deal of progress has been made in only 7 weeks, and thanks to Firefox’s new rapid release cycle, each improvement made will make its way into a final release in only 12–18 weeks. (These improvements are available earlier to users on the Aurora and Beta channels.) Firefox 7 is the first release to benefit from MemShrink’s successes, and the benefits are significant.
Quantifying the improvements
Measuring memory usage is difficult: there are no standard benchmarks, there are several different metrics you can use, and memory usage varies enormously depending on what the browser is doing. Someone who usually has only a handful of tabs open will have an entirely different experience from someone who usually has hundreds of tabs open. (This latter case is not uncommon, by the way, even though the idea of anyone having that many tabs open triggers astonishment and disbelief in many people. E.g. see the comment threads here and here.)
Endurance tests
Dave Hunt and others have been using the MozMill add-on to perform “endurance tests“, where they open and close large numbers of websites and track memory usage in great detail. Dave recently performed an endurance test comparison of development versions of Firefox 6, 7, and 8, repeatedly opening and closing pages from 100 widely used websites in 30 tabs. The following graphs show the average and peak “resident” memory usage for each browser version over five runs of the tests. (“Resident” memory usage is the amount of physical RAM that is being used by Firefox, and is thus arguably the best measure of real machine resources being used.)
Obviously the measurements varied significantly between runs. If we do a pair-wise comparison of runs, we see the following relative reductions in memory usage:
- Minimum resident: 1.1% — 23.5% (median 6.6%)
- Maximum resident: -3.5% — 17.9% (median 9.6%)
- Average resident: 4.4% — 27.3% (median 20.0%)
The following two graphs showing how memory usage varied over time during Run 1 for each version. Firefox 6’s graph is first, Firefox 7’s graph is second. (Note: Compare only to the purple “resident” lines; the meaning of the green “explicit” line changed between the versions and so the two green lines cannot be sensibly compared.)
Firefox 7 is clearly much better; its graph is both lower and has less variation.
MemBench
Gregor Wagner has a memory stress test called MemBench. It opens 150 websites in succession, one per tab, with a 1.5 second gap between each site. The sites are mostly drawn from Alexa’s Top sites list. I ran this test on 64-bit builds of Firefox 6 and 7 on my Ubuntu Linux machine, which has 16GB of RAM. Each time, I let the stress test complete and then opened about:memory to get measurements for the peak resident usage. Then I hit the “Minimize memory usage” button in about:memory several times until the numbers stabilized again, and then re-measured the resident usage. (Hitting this button is not something normal users do, but it’s useful for testing purposes because causes Firefox to immediately free up memory that would be eventually freed when garbage collection runs.)
For Firefox 6, the peak resident usage was 2,028 MB and the final resident usage was 669 MB. For Firefox 7, the peak usage was 1,851 MB (a 8.7% reduction) and the final usage was 321 MB (a 52.0% reduction). This latter number clearly shows that fragmentation is a much smaller problem in Firefox 7.
(On a related note, Gregor recently measured cutting-edge development versions of Firefox and Google Chrome on MemBench. The results may be surprising to many people.)
Bookmarks
Nathan Kirsch from Legit Reviews performed a simple test comparing Firefox 5 against Firefox 7. He clicked “Open all in Tabs” on a bookmark bolder containing 117 bookmarks — causing each bookmark to be opened in a separate tab. Once they all finished loading, he used the Windows Task Manager to measure the “private working set” (which is not that same as “resident”, but will correlate strongly with it). Firefox 7 used half a GB less memory than Firefox 5 — a 39.7% reduction.
Conclusion
Obviously, these tests are synthetic and do not match exactly how users actually use Firefox. (Improved benchmarking is one thing we’re working on as part of MemShrink, but we’ve got a long way to go. ) Nonetheless, the basic operations (opening and closing web pages in tabs) are the same, and we expect the improvements in real usage will mirror improvements in the tests.
This means that users should see Firefox 7 using less memory than earlier versions — often 20% to 30% less, and sometimes as much as 50% less — though the improvements will depend on the exact workload. Indeed, we have had lots of feedback from early users that Firefox 7 feels faster, is more responsive, has fewer pauses, and is generally more pleasant to use than Firefox 4, 5 and 6.
The reduced memory usage should also result in fewer crashes and aborts on Windows, where Firefox is built as a 32-bit application and so is typically restricted to only 2GB of virtual memory.
Mozilla’s MemShrink efforts are continuing. The endurance test results above show that development versions of Firefox 8 already have even better memory usage, and I expect we’ll continue to make further improvements as time goes on. We also have plans to improve our testing infrastructure which should help prevent future regressions in memory usage.
66 replies on “Firefox 7 is lean and fast”
Now hopefully Mozilla marketing will make good use of this release. We should be able to win back some old friends whom moved to Chrome.
I’m using aurora, but I still have defunct process. Is that a trick, or a bug?
Great job for the improvement though!
Fser: a defunct process? I don’t understand. Can you explain more?
fser 7526 4.2 12.4 1220068 496832 ? Sl 10:27 10:33 /home/fser/bin/firefox/firefox
fser 7527 0.0 0.0 0 0 ? Z 10:27 0:00 [firefox]
fser 7561 8.3 1.5 474100 63428 ? Sl 10:27 20:37 /home/fser/bin/firefox/plugin-container /usr/lib/flashplugin-nonfree/libflashplayer.so -greomni /home/fser/bin/firefox/omni.jar 7526 true plugin
I’m afraid I know what this is, since you’re apparently on X11. This is probably the separate process that we use on X11 to query OpenGL information. We do that in a separate process as, depending on drivers, this can be a very crashy thing to query.
It terminates quickly but stays as a zombie until Firefox reads the data (through a pipe) and kills it. As an experiment to confirm this theory, if you go to any WebGL page such as
http://webglreport.sourceforge.net/
then the zombie process should die immediately. I filed a bug about that:
https://bugzilla.mozilla.org/show_bug.cgi?id=677531
Still have it (the page is currently open):
$ ps -ef | head -1 ; ps -ef |grep firefox
UID PID PPID C STIME TTY TIME CMD
fser 3074 1 1 Aug17 ? 00:27:33 /home/fser/bin/firefox/firefox
fser 3230 3074 0 Aug17 ? 00:00:00 [firefox]
fser 3266 3074 1 Aug17 ? 00:31:01 /home/fser/bin/firefox/plugin-container /usr/lib/flashplugin-nonfree/libflashplayer.so -greomni /home/fser/bin/firefox/omni.jar 3074 true plugin
fser 10669 3074 0 10:32 ? 00:00:00 /home/fser/bin/firefox/plugin-container /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so -greomni /home/fser/bin/firefox/omni.jar 3074 true plugin
fser 13003 12432 0 14:37 pts/4 00:00:00 grep firefox
By the way, the sanitize engine has removed the <defunct> part in the process list.
I have been using Chrome since version 1. I have recently tried out Firefox 5.01 as certain websites were breaking in Chrome. I really like what is being done to Firefox. There are a lot of positives that I see. The place where Chrome is really winning is the perceived speed that is visible during the rendering process of the web pages. I don’t care about the synthetic benchmarks but Firefox is catching up. It is definitely the second fastest browser after Chrome in terms of rendering in real world conditions. The resurgence of Firefox is inevitable. The integration of the extensions is unmatched. I have now uninstalled Chrome 13 stable and using this. I like the experience. I do miss the auto translate feature in Chrome. Other than that, brilliant job, team. Thank you.
By the way, Firefox is the only one that really renders all pictures and all the websites I visit perfectly. Chrome and IE9 break too many websites. It is a pain to press that compatibility mode button. Pictures are crisp with no defects and text is really pleasing to the eye. Scrolling is smooth and video play back is good. No crashes since a week (fingers crossed).
Rohit: Excellent! Thanks, it’s really nice to hear positive feedback π
Mozilla Marketing has spun “improved performance” so often, despite regressions, that nobody should believe a word they say anymore.
Thankfully a straight-talking Aussie developer like NJN has broken through all the marketing babble and proven performance really has improved, finally!
All hail straight-shooting champion Aussie developers like NJN (and me?, LOL).
NJN you seem to be having a bit of trouble with this new blog theme. What does the first heading possibly mean: “tl;dr” ?
βtl;drβ = “Too long; didn’t read” this is internet slang
This is excellent! I am very pleased to run the nightlies. Don’t forget that firefox is commonly used with addons that can hold on to memory longer; I’d love to see endurance tests applied with each of the top 10 add-ons (with some pre-configuration of ABP filters and such for realism). Firefox is also used with histories that can grow large (although I can no longer set a minimum history lifetime); history archival similar to chrome’s would be very desirable.
Hey Tobu,
It is possible to run endurance tests with add-ons installed. See my blog post on the subject here: http://blargon7.com/2011/03/automated-firefox-tests-with-add-ons-installed/
Unfortunately Dave, NJN has previously admitted that it’s very hard to isolate Add-On memory consumption: http://tinyurl.com/3qrp8pr
Your points suggesting that real usage with add-ons and extensive history would make for better tests are interesting. I have been running Aurora 7 since NJN said it included the big fixes however I wasn’t going to lose all my settings add-ons and so forth just to try the first Firefox with much improved memory management. After all I’d heard this claim before. So I’ve been running it with my old profile that dates back to November 2008 and I run 33 Add-Ons and the Flash plugin. I’m happy to report that the memory management, and therefore overall, improvement in performance, is real! The only trouble I’ve noticed is that the awesomeBar still hangs every now and then when I’m trying to type in an address. This behaviour though, in my experience, goes back to day 1 of the (perhaps not so …) ‘awesome’ bar. Even using Vacuum Places extension makes little difference. NJN has found a hole in the SQLite code (http://tinyurl.com/3etofww | http://tinyurl.com/3e4kjcd) though which may end up helping this, not sure.
Thank you! These new Python automation modules are great things to build on.
@pd, there’s no need to isolate. Just run it with one addon’s enabled state changed and compare the total.
I use the web about 12 hours every day between home and work and I’ve never seen anything like that. How about we stick to plain old english?
> I use the web about 12 hours every day between home and work and Iβve never seen anything like that.
You’re doing it wrong
@pd
The last time I brought up the tl;dr as a understandability issue (being used on the wiki) I was harangued on IRC because it’s “common internet slang” that “everyone knows”.
(I use the net as much as you and that was the first time I’d seen it used. This is the third.)
This particular piece of so-called slang promotes the sort of short-attention-span lazy thinking that is the opposite of the mentality NJN has demonstrated in his approach the MemShrink (in so far as I can determine based on reading this blog). So it’s quite surprising on more than one level.
Clear, simple and concise written communication is invaluable nowadays more so than ever. Aside from the content on this blog, the clarity of the writing has been the other highlight for me.
Not everyone on the Internet uses IRC. I’d suggest the subset of IRC users is probably very small – though I have no evidence of that.
Vote 1 for plain, concise and clear written communication! Never more important than these days of SMS, Tw(sh)itter, IRC and so forth.
I see tl;dr all the time, and it’s one of those things I mostly see ‘non computer people’ people getting confused over (e.g. grandparents). For a personal blog, I think it’s perfectly fine to use, and a blog like this, it’s… Debatable. But if this were to be in official documentation and the like, I must agree – Nuke it from orbit.
tl;dr:
Don’t tl;dr for any official documentation or the like that an end-user may read, but for personal things I say it’s fine.
Hm.
I read a TL;DR; about 5 times a day.
It’s a very common way to head a summary before a long/technical post.
I don’t know to what extent 3 improved on memory from 2, but 3.5 and 3.6 are both hogs–though obviously not to the extent of 4. I was never able to tell if memory was the issue or not, but Firefox 3.6 choked on running many windows (not tabs, mind you, but some of those windows might have multiple tabs) and I found its startup time–measured in time from launch to when the CPU settled down and made the browser truly usable–went up by a factor of tenfold. Not kidding. I went from a startup of about 90 secoonds to 2 minutes in 3.5, to 20 minutes in 3.6. I’d have to say I’m probably using more like 50-60 tabs rather than 100, but it’s spread out over 15-25 windows at any given time. I usually keep only one tab per window loaded, thanks to the wonderful BarTab extension.
I don’t know if 3.6’s massive problems ever improved because I’ve never gone back to it. (I don’t even know, though I’m curious to find out, if the persona implementation ever improved, because gads did that ever suck. No local storage of personas for easy switching? Can’t be used with in conjunction with a theme? Seriously?) What I would very much like to know however is if Firefox 7 is any less leaky than 3.5 (or even 3.6) or at least how its at-rest memory use compares. 3.5 remains stable overnight, but usage does creep up over time and I’m sure zombie compartments and fragmentation are to blame. Even that aside, I consider 3.5’s at-rest memory high. Comparing 7 and 8 to 4-6 is apples-to-oranges as far as we late-adopters are concerned.
Getting more and more impressed about the MemShrink effort for each new blog post Nicholas. Fantastic work you and your team are doing.
Also great news and I hope it at some stage soon is going to go from being an effort to be an integral standard part of the future development of Firefox.
I also hope that when the lion share of work been done with the core Firefox, you will also start looking into extensions and how things can improved there too. I’m sure it wont be to hard to find things that are done wrong that are quite common there and can end up in a FAQ or something.
Maybe even possible to create code review tools that can scan the source code and find issues?
Hi there,
nice that so many people are working on it!
I am using Firefox since Version 2.x I think, but at the moment I am shortly before a complete deinstallation and a browser change. Firefox is simply unusable, at the moment it takes about 18000 MB RAM and permanently 45-50% CPU on my Notebook . Writing this email is very close to a punishment, because the whole Win7-64bit freezes every few seconds. And there are only 25 FF-Windows and 85 Tabs open… With older FF-versions (5.x) the CPU usually didn’t lock the whole system and FF took never more than 1200-1300MB – with 350 Tabs open! If I search in my backups I am sure I can find a session manager SaveState…
Greetz, Alex
Are you seeing this bad behaviour with FF7?
i still think 3.6 was the best browser to come out of mozilla stable in terms of memory usage, have you done any comparison with 3.6?.
MAk: I tried twice doing the 150 tab stress test on a trunk build of 3.6 and it crashed both times π
Ohhh, that is sad, i remember using 3.6.* version and being the most happy i ever was with firefox’s memory handling.
I have been using Firefox ever since I started using internet big time. With FF 2 and 3, I never had a problem with the initial tab loading. But in 4+ whenever I open the first two tabs, I will have to wait for around 5 seconds because it hangs and then becomes stable. Can the guys at Mozilla address this issue?
By the way, congratulations for doing a great job on FF. I have used FF8 and it even runs on my desktop that Adam and Eve bought. π I used Chrome and it threatened to murder my desktop.
Once a FF fan, always a FF fan. π
I write for
http://fastestfox.wordpress.com/
and maintain a fan page here:
https://www.facebook.com/pages/Firefox-4/101547596592952
Hi Nicholas Nethercote,
Your Quote: ‘I ran this test on 64-bit builds of Firefox 6 and 7 on my Ubuntu Linux machine, which has 16GB of RAM.’
Checking out the testing you’ve mentioned to do a comparison on my machines, I had a problem with the Gregor Wagner memory stress test called MemBench, using Window 7. The routine finished with the opening of all the URLs but only 1 tab was present after the test. I made sure the Tab Options where set to open on a window.open call to open as a tab. I performed on FF 6. Beta, Aurora and Nightly as current update.
Nicholas, did you have the test site open up all URLs in independent Tabs for a test on Windows ?
Is there something that I need to apply to have the test open up within independent tabs for all URLs ?
Since there was a problem for my testing, I modified the code in the test MemBench site you posted to open the MemBench URLs into independent Tabs to monitor the memory usage.
P.S. I been out of pocket on summer vaction, I’m now returning back to looking into areas I’ve personally discovered toward the helping the MemShrink effort. I’m very glad that the MemShrink team has done such an
outstanding job on correcting the memory issues !
Regards,
richard
IDEVFH: it’s probably the pop-up blocker blocking the new tabs. You need to allow http://www.gregor-wagner.com to create pop-ups — Firefox should give you a message about this at the top of the page, and give you an option to permit pop-ups from that domain. And then you need to go to about:config and change dom.popup_maximum to a number larger than 150, otherwise it’ll stop after 20.
Hi Nicholas,
That was the problem. I never seen the message Firefox should have given me about the popup. Don’t know why. But problem solved !
Many Thanks !
Regards,
richard
IDEVFH: good. I’d be interested to see if you get similar results.
Wow , I am so happy about it , Lot of firefox users move to chrome and i hope they get back to firefox soon.
Thanks firefox for this inprove.
ok, who are you trying to fool?. The memory usage still high because is BAD CODED. Instead of debug and make the code better this people is doing EXACTLY the OPPOSITE. Looks like m$ is not the only one that copy and paste code. And in this case is even worse, because they dont optimize the code. Remember that 3.6.x uses 10% or less of that this so improved version of 7.
roberto: Can you give more details about the supposed 10% difference between 3.6.x and 7? Did you perform some tests?
Patches are welcome.
Actually, they’re not. I tried submitting a patch for a pernickity bug about a year ago, after spending days tracking it down through the source, and it was soundly refused on the basis that it didn’t solve the problem in the “Netscape way.”
That was the day I wrote Mozilla off as a genuinely open community.
My last post was consumed without notice of moderation, presumably because of my e-mail address.
I just wanted to counter this “Patches Welcome” thing with my own experience trying to contribute a patch. I can’t recall the specific bug now, it’s been many years ago, but I do recall that it was open at least as far back as FF1. Yes, that is a ‘1’.
However, the patch I submitted to the bug report (which I believe remains open to this day) was soundly rejected by one individual who worked for Mozilla. Amongst a large number of accolades and thank yous, one Mozilla employee had to be the party pooper.
His reason, if my memory serves me correctly, paraphrased: “We won’t accept this patch because it doesn’t solve the problem the Mozilla way.” When pressed precisely what the “Mozilla” way was, he refused to refer me to any documentation on the matter. I had already read the coding guideline document. I had already read other documents on contributing to the project. What else was there? It was a total drive-by — I never heard from this individual again.
As a potential contributor to the Mozilla project, I was slapped in the face.
So, in my estimation, no, patches are not welcome. Not, that is, unless you’re already a member of the “in” crowd.
Munch: posts by new posters are moderated. I’m in Australia so my timezones are probably different to yours, which explains the delay in moderation.
As for your experience, I’m sorry it happened. Sometimes people are unreasonable. If you try again hopefully you’ll get a better response this time.
Hi Nicholas,
Here’s my memory test using Gregor Wagner MemBench for browsers ( Aurora ) and ( Nightly ) ONLY.
No Add-ons activated.
Aurora-Nightly-Memory-Test
Regards,
richard
Is there an alternative to crashing when memory is low? Why doesn’t FF page out some stuff to disk and free up some memory in its heap, rather than crashing (with no error message)?
OisΓn: We’re working on that π See https://bugzilla.mozilla.org/show_bug.cgi?id=664291 and https://bugzilla.mozilla.org/show_bug.cgi?id=670967.
@Nicholas
That’s great to hear, thanks for the links!
My bad habits of leaving a hundred tabs open have been causing a lot of crashes on the 32-bit Vista machine I use in uni. I went from FF5 to FF7 after that earlier post and it was pretty much the same; if anything, it crashed a little sooner.
Eventually I worked around it by using a bookmarklet that removes Javascript events/timers and plugins, and basically clicking it on every open tab. That dropped memory usage by about a third… hopefully it’ll do until the allocator is patched π
“Eventually I worked around it by using a bookmarklet that removes Javascript events/timers and plugins,” <—- what bookmarklet is this? Google is of no help.
please don’t have firefox maintain it’s own swap file.
every OS you run on already does swapping at the OS layer, trying to figure out when firefox should swap separately from that will be a disaster because you have no way of knowing what swapping the OS has already done.
Remember that firefox was started because mozilla was bloated, now firefox has become bloated and needs to get back to it’s roots of being a fast browser.
How/where does Firefox maintain its own swap file? I’m not even sure what you mean by that.
there was a suggestion that firefox page things out to disk when it ran out of memory, that would effectivly be maintaining it’s own swap file, and I was attempting to respond to that suggestion
testing — my post didn’t appear, with no indication of moderation either. Is it because I use a spam trap e-mail address?
The problem is this odd version race. Firefox 6 is no more than Firefox 4.2, and that’s how it should’ve been labelled. Mozilla should stop trying to copycat Chrome and focus on its own problems.
Looks good: a great way to go faster is to use less memory.
I’m VERY happy to see Mozilla focused on memory management! Though Firefox has been my main browser ever since Firefox 1, for years now I have been very disappointed with its poor memory management. And though many people complained about memory leaks, I would often see devs denying that they were a problem, even blaming the anti-virus software, the operating system, or extensions (though yes these can be a big problem). But it was clear to anyone that even with a brand new, clean operating system that you could get Firefox to over 1GB of used memory, by and large leaked, in a day’s use. And on any system, regardless of how much was on it or how old it was, Chrome’s memory remained very low.
I just got FFX7b tonight so I can’t comment on its memory management yet, but I will just say that I’m very happy to see the memshrink initiative! I hope that it continues far past FFX7 and we can really see a browser with the best features, best extensions and SOLID memory management. π Good job, team!
Great change on this Beta version, i think the memory use change will be optimized for notebook/netbook user.
Memory efficiency makes me happy! (That’s the reason I switched to Chrome, but I’d rather use Firefox.)
I’m glad to see firefox getting it’s act togeather with memory management, but there is one killer feature that keeps me using Chrome, when there is a memory problem, Chrome kills a plugin, or a tab at a time. Firefox kills all windows and all tabs at once. On my machine at work (dual processor, 4G ram) it can take over 10 minutes to get firefox started and all the windows into the correct desktops again.
10 minutes? It shouldn’t take nearly that long, it sounds like something is busted. Trying a new profile is a good idea.
upgrading to firefox 6 and creating a new profile did _not_ help matters.
I created a new profile and copied the following files over to it
dlang@dlang-desktop:~/.mozilla/firefox/default.1iy$ cp -pR sessionstore* prefs.js bookmark* cert* cook* permissions.sqlite places.sqlite* mimeTypes.rdf ../vd6vxov5.dlang/
the resulting about:memory
Explicit Allocations
2,723.64 MB (100.0%) — explicit
βββ2,558.21 MB (93.93%) — heap-unclassified
βββββ131.66 MB (04.83%) — js
β ββββ99.00 MB (03.63%) — gc-heap
β ββββ17.45 MB (00.64%) — tjit-data
β β βββ17.45 MB (00.64%) — (2 omitted)
β ββββ15.21 MB (00.56%) — (3 omitted)
ββββββ20.88 MB (00.77%) — layout
β βββ20.88 MB (00.77%) — all
β ββββ0.00 MB (00.00%) — (1 omitted)
ββββββ12.89 MB (00.47%) — (2 omitted)
Other Measurements
3,411.34 MB — vsize
2,741.00 MB — heap-committed
2,709.27 MB — heap-used
2,648.54 MB — resident
31.73 MB — heap-unused
3.75 MB — heap-dirty
0.39 MB — gfx-surface-image
0.17 MB — canvas-2d-pixel-bytes
this is after hitting minimize memory use several times
It’s hard to interpret this about:memory output without knowing what sites you had open at the time. 93% heap-unclassified is extremely high, but the reporter coverage in FF6 isn’t very good. FF7 (currently in the Beta channel) has better coverage and substantial memory efficiency improvements, FF8 (currently in the Aurora channel) is even better on both counts, FF9 (currently in the Nightly channel) is a bit better again.
In other words, we’re actively working on all this stuff and have been for several months, but it takes 12–18 weeks for any individual improvement to make it through the pipeline into a final release. There’s also the possibility that there’s something weird happening with your configuration (do you have many add-ons installed? Some add-ons behave badly.) But it’s hard to tell from this limited information.
In this case even firefox 8 doesn’t get more detailed.
the only addon that’s enabled is the icedtea java plugin. I then installing noscript to see if it blocks enough to cut things down, but it makes things eat a bit more memory (2.7G instead of 2G)
I’ll e-mail you my sessionstore.js so you can see what sites I’m connecting to (although some of them are internal to my network)
without noscript
2,047.69 MB (100.0%) — explicit
βββ1,972.36 MB (96.32%) — heap-unclassified
ββββββ51.99 MB (02.54%) — js
β βββ28.41 MB (01.39%) — (25 omitted)
β βββ23.59 MB (01.15%) — compartment([System Principal], 0xfffffffff209c800)
β βββ13.22 MB (00.65%) — gc-heap
β β βββ13.22 MB (00.65%) — (7 omitted)
β βββ10.37 MB (00.51%) — (8 omitted)
ββββββ11.83 MB (00.58%) — (5 omitted)
ββββββ11.50 MB (00.56%) — layout
βββ11.50 MB (00.56%) — (2 omitted)
Other Measurements
0.58 MB — gfx-surface-image
21.36 MB — gfx-surface-xlib
2,034.93 MB — heap-allocated
2,041.00 MB — heap-committed
1.36 MB — heap-dirty
6.07 MB — heap-unallocated
2 — js-compartments-system
84 — js-compartments-user
24.00 MB — js-gc-heap
2.83 MB — js-gc-heap-arena-unused
0.00 MB — js-gc-heap-chunk-clean-unused
1.22 MB — js-gc-heap-chunk-dirty-unused
16.89% — js-gc-heap-unused-fraction
141 — page-faults-hard
678,608 — page-faults-soft
1,980.27 MB — resident
2,432.41 MB — vsize
with noscript
2,700.55 MB (100.0%) — explicit
βββ2,618.72 MB (96.97%) — heap-unclassified
ββββββ50.63 MB (01.87%) — js
β βββ27.24 MB (01.01%) — compartment([System Principal], 0xfffffffff219c800)
β β βββ15.87 MB (00.59%) — gc-heap
β β β βββ15.87 MB (00.59%) — (7 omitted)
β β βββ11.37 MB (00.42%) — (8 omitted)
β βββ23.39 MB (00.87%) — (32 omitted)
ββββββ16.43 MB (00.61%) — (6 omitted)
ββββββ14.77 MB (00.55%) — layout
βββ14.77 MB (00.55%) — (2 omitted)
96.32% heap-unclassified in FF8 is extraordinary, I’ve never seen it anything like that high. Something very weird is going on in your case. Can you disable this IcedTea java plug-in, just to see if that’s the problem? And anything you can send me in private would be very helpful, thanks.
And process separation is planned for Firefox, see https://wiki.mozilla.org/Electrolysis.
As for Chrome, the “one process per tab” model is how it’s commonly understood, but it’s actually much more complicated than that. See http://www.chromium.org/developers/design-documents/process-models for lots of gory details. And I’ve heard that they’ve moved to a coarser granularity (i.e. fewer processes, more stuff in each process) over time, but I’m not certain about that.
the page on Electrolysis talks about things in progress with due dates of early 2010 so it hasn’t been updated for quite while.
I’m not as concerned about the exact mechanism as I am about the result, when my machine runs out of memory, some chrome plugins get killed, some chrome tabs may get killed (but in a way where they are still there and I can just hit ‘reload’), but firefox dies completely
Shorter, not longer memory is what I am looking for in plugins. The convenience versus the intrusion of longer plugin memory is a bad trade-off if you ask me. chromes speed comes from proprietary behaviors, exactly NOT what I’m looking for. Raw speed and Choice beats pretty and intrusive all day long. my opinion. Kill process at close please. Don’t help me any more than i ask; a good browser.
I stop using ‘Internet Explore’, because with every update something on my PC would get screwed up. Now everytime firefox updates (guess what?)… I have found strings, stans or whatever you call them on your updates with the word PROFILE/PROFILING in them.
Maybe you have heard these sayings “If it works don’t fix!!!”(because it is not just young kids that have PC’s, only adults tends to stay with equipment alot longer and NOT change every other week) YOU”RE NOT HELPING THE , 68% OF YOUR USERS (OLDER), YOUR NOT EVEN IMPRESSING US. If there is not going to be a difference Firefox and Internet Explorer why change to you?
“When you find yourself in a whole STOP digging”
Thank You