Why not have bug fix patches for older releases? The problem isn't that these new releases are mostly just bug fixes, but that they're the ONLY release that's supported.
This is only a problem if
* we break stuff that used to work, or
* we make changes you don't like,
right?
In the first case, we rely on people testing our aurora and beta builds to find regressions. (Remember that Mozilla is a non-profit; we simply don't have the QA resources that Microsoft, Apple, and Google have, and even Google relies on community testing.) You can help by running Aurora.
In the second case...we try to make good changes, and we try to give people the option to revert their UI back to the old way, either through options in the browser or extensions. I understand that our track record here is mixed.
I don't claim it's perfect, but understand that we have limited resources. If we could, we'd love to support every version of Firefox we ever released forever. But the browser space moves quickly, and supporting just one release frees up engineering resources for things everyone wants, like MemShrink.
So, is it accurate to say that Firefox 9 is really something around 4.2.x or 4.3.x under standard numbering?
Yes, pretty much. Which actually a big part of the complaint: Firefox uses version numbers very differently from the way they are commonly understood.
Understand that our development process is unlike most other projects'. Like Chrome, we have three development versions in flight at once (nightly/canary, aurora/alpha, beta), and when we release, we promote nightly to aurora, aurora to beta, and beta to the release. In the X.Y model, the assumption is that you have only two versions in flight at once: X.(Y+1), which contains bugfixes, and (X+1).0, which contains new features.
Because our development model is so different, the X.Y numbers don't make much sense. You could call it 4.2, 4.3, and so on, but because every release is equal, when do you increase the major version number? When you feel like it?
Maybe you disagree with our release process. That's a fair criticism; it's not perfect. We can argue about the release process in a separate thread. But the version numbers follow logically from the process, I think.
Please stop releasing new versions of firefox and fix the version you have
You do understand that the new releases have bug fixes, right? Probably the majority of patches going into any given release are bugfixes.
The main cause of random freezes should be fixed in the latest release, Firefox 8. If you're still seeing freezes, please file a bug and cc me (jlebar) and I'll follow up.
I did leave it open for a while till it stopped shrinking and I also clicked on "minimize mem usage".
FWIW the yahoo thing is still there despite the tab not being there. I did reopen that link again some minutes ago. How long do I have to wait till it goes away?
If you click minimize memory usage, everything should go away immediately. If you don't, I'm not sure how long you have to wait; five minutes (without touching Firefox) should be sufficient.
Are you running with extensions? It's probably an extension bug which is causing that yahoo compartment to stay there. If you can reproduce without any extensions, please file a bug and cc:jlebar. If not, then you may want to get in touch with the extension author (and you're welcome to file a bug and cc me anyway).
p.s. Is the Content Security Policy stuff gaining traction?
FWIW, it looks like you may not have left Firefox idle long enough to trigger a GC before you took this about:memory screenshot -- there's still a compartment for Yahoo Finance open. You can click "minimize memory usage" at the bottom of the page to force all our timers to fire.
To me what actually counts is whatever that would make the computer start to swap- even if the rest are small/tiny. That's the main thing right?
Right. This also means that peak memory usage -- which isn't what people on Slashdot usually talk about -- is just as important, if not more important, than memory usage after closing all tabs. It's when we're at our peak that we're most likely to cause swapping.
So Is it correct to say that Mozilla (even 7.0.1) often can't return some of the unused private bytes, and that can keep growing as the user opens and closes stuff?
I'm not sure if that growth is unbounded. I'm also not sure how much this growth affects our peak memory usage -- a lot of this fragmentation leaves gaps which we can fill in when you open new tabs.
But yes, it's correct that no version of Firefox uses as little memory after you close all tabs as it does when it first starts up.
From what I see, with Chrome opening and closing some windows/tabs usually frees up all the memory involved - the process just goes away returning the memory to the OS (and letting the geniuses in charge of the OS take care of fragmentation - not the browser's problem anymore;)
Well, you can't fragment physical memory, because all pages are the same size! (Well, modern chips expose different-sized pages, but I'm not aware of this being used on any consumer device.) The heap fragmentation in this latest about:memory dump is pretty bad...
But architecturally, Chrome definitely has a leg up on us here. There's only so much we can do as-is. We're working to make architectural changes to match Chrome, but it's slow going.
So I see the 110MB "explicit". What's using the rest?
Let's see. Part is heap fragmentation. That's heap-committed - heap-used = 25mb. The rest is probably code. On my Linux machine, we load about 35mb of code (about half are shared libraries). 25mb + 35mb + 110mb = 170, which is very close to your 172.5mb of resident.
There are a lot of things here that we can improve. urlclassifier (phishing protection) does not need to use 20mb of memory; someone is working on this. We don't know where 1/3 of your memory is going (heap-unclassified); it's a slog, but we improve this a little in each version. 25mb of heap fragmentation is more than I'd like, and we're working to update our malloc library, jemalloc, to the newest version, which will hopefully improve this. I've also done some work to reduce the number of calls we make to malloc() in the first place, which has helped some.
As you can see, there's room for improvement, but we have to fix a number of small things to get a big change.
The vsize value [342mb] seems different from the windows reported VM size (about 170MB).
I think task manager may be counting only private bytes, but Firefox is counting everything in its virtual address space. On my Windows 7 VM, Firefox's vsize matches Process Explorer's virtual size column. If these don't match for you, that's probably a bug!
Didn't the Mozilla bunch claim the memory problems were fixed in version 3, 3.5, 3.6, 4, 5 and version 6?
As I recall, the claim was that memory problems were addressed in 3, 3.5, 3.6, 4, 5, and 6, not that your memory problems were fixed. It was before my time, but there was a concerted memory-usage effort in the 3 - 3.5 timeframe. You're right in that it's only in Firefox 7 that the results of our latest big memory push have seen the light of day. But that doesn't mean we didn't fix any problems in the meantime.
Go ahead blame me for not wanting to waste my time upgrading only to face the same problem.
In the amount of time it took you to write this post to Slashdot, you could have done each of these browser upgrades. We even save your tabs across upgrades. But like I said, my issue isn't that we lost your trust through bad PR -- that's our fault -- but rather that you claimed that memory usage is "still a problem" when you hadn't tried the latest version!
Is it supposed to still be using 180MB?
You can open up about:memory and see exactly where that 180mb is going, if you're curious. I'd love for our after-closing-tabs memory usage to be smaller, but with our current architecture, we're never going to be as small after you've used the browser as when you first start up. 180mb isn't abnormally high.
We've improved things in upcoming versions, too, but I'm not promising miracles.:)
I don't understand why people get so mad about this.
I'm sorry that you don't trust Mozilla to deliver on its promises any longer. I wish you'd check out the new version of Firefox, because we've put a lot of work into improving it. But hey, it's free software, and if you want to run a browser released in January 2010, more power to you!
The good news is that Firefox, Chrome, and Opera work on Windows, Mac, and Linux. You have options; nobody's making you use Firefox.
But maybe next time before you assert that memory usage is "still a problem", you could try the latest version. If you never upgrade your browser, you're never giving us a chance to fix anything.
Safari uses Preview internally, I believe. That's a C/C++/Objective C program, with all the security vulnerabilities that go along with that.
The news here is that Mozilla is trying to develop JavaScript which renders PDFs. So long as our JS engine is secure, this PDF reader would be secure. (And if the JS engine isn't secure, the whole browser isn't secure, so adding the PDF viewer isn't an attack vector.)
1) The poor performance and the extreme memory usage. Yes, this is still a problem. It's easily reproducible with fresh Firefox installations.
We have a whole team of engineers devoted to memory usage, and a second team devoted to performance. If you have issues you can reproduce, especially on a clean Firefox install, we'd love it if you'd file a bug. We can only fix problems we're aware of, and we're not aware of any huge leaks in the versions we're shipping.
5+ hours of CPU time for a single build, 25+ minutes of wall time, as measured on a workstation (dual-E5620 i.e. 2x quad-core 2.4GHz HT, with 24GB of RAM, no SSD).
Do you see car designers moving the pedals around to different places, or putting the headlight switch in the back seat because it looks "cool" there, or removing the steering wheel and putting in a tiller because they don't want to look "dated"?
Consider the Prius. The Prius's dashboard isn't in the usual place. It has a digital speedometer and no tackometer. You start it by pushing a button, not turning a key. You can unlock some models just by walking up to it. Oh, and Toyota just redid the body design this year.
Maybe you don't like the Prius. That's fine. But you'll grant me that lots of people do like it, despite these unnecessary changes. Toyota must be doing something right.
When a product gets to a certain level of maturity, it doesn't need any more change, unless it can be shown that that change really is a benefit.
I think what you mean is, when a product gets to a certain level of maturity, it doesn't need any more change, unless I really like that change. But the fallacy I keep hearing on Slashdot is that what I like is the absolute measure of what's good in the world.
If the changes we've made to the UI are really so heinous, a group of people will come together and either provide security updates to Firefox 3.6 until the end of time or maintain an extension which brings FF 3.6's UI to new versions. I don't think that would be so bad. To each his own.
What you need and for 2 years have claimed is 'too hard' (then you've got a problem -- you have a non-object oriented, monolithic core of code that is trying to emulate (run) objected oriented, separate tasks? You don't see that as being a fundamental design issue?
It is a fundamental design issue. That's why it's hard.
Even the linux kernel can split off sub-processes to do work -- it doesn't try to do everything in 1 event loop, certainly it should be easier to achieve this in a browser
It's not that I mind 'UI Improvements' but as the guy you were quoting phrased it 'UI changes.' It is common to act like the two are synonymous but to me it seems like the vast majority of 'changes' are not 'improvements.' A lot seems to be tinkering for it's own sake. Which is fine in it's place. The world's defacto standard web-browser just is not the place for it.
I hear this all the time on Slashdot, and to be honest, I don't get it.
I understand when people don't like X or Y change, but the argument is often, as it is here, against change in general. Is the idea that Firefox should perpetually be stuck in the 2009? That Firefox 3.6 is the pinnacle of UI design, and that there's nowhere to go but down? Honest question.
To most people, the user interface *is* Firefox. We can't leave this static and expect to be relevant in three years. There are simply too many good ideas out there being implemented in other browsers. If you want a UI which will never change, use Lynx.
You're welcome to disagree with the design decisions which have been made, but I can assure you that they weren't made simply for the sake of tinkering with things. We have a team of really sharp designers who put a tremendous amount of thought into how Firefox looks and feels.
One more note here for the benefit of Slashdot (hi!) and anyone else who's not clear on this issue or how our bug tracker works.
We made the decision not to make this configurable long, long ago, even before we WontFixed this bug in comment 59 (over a year ago itself). Accordingly the bug is closed because that reflects not only our current stance but the position we've had for a very long time.
This does not mean either that we will never listen to user feedback, or that we used to be listening on this bug but decided to stop. The issue is that our bug tracker is specifically about tracking what we consider to be bugs, not a general forum for feedback and debate on our design decisions. That means that in general (this bug included), we can and will decide not to address particular requests, and when we do, commenting on the closed bug is not going to make us change our minds. On the contrary, we will not hesitate to lock things down in the bug tracker precisely to prevent things from spiraling out of control or misleading people into sharing their feedback here instead of where it's helpful
We have other venues such as the chromium-discuss mailing list and our feedback forums where it is appropriate to share your opinions. The forums are a place where we are set up to track user feedback and surface the most critical issues to the team without impacting the productivity of us developers who are busy trying to make Chrome work better.
We don't promise we'll change our minds, but we're not hostile to you expressing your point of view. This is just not the correct forum to do so.
These problems all exist because Firefox stubbornly clings to the antiquated and idiotic notion of having all tabs and windows run in a single process. [snip] When is Firefox going to stop wasting time on useless UI changes and actually fix their architecture?
I think "stubbornly clings" is not supported by our actions. The multiprocess Firefox project is called Electrolysis. It's been going on for about two years now. We moved plugins to a separate process back in Firefox 3.6.4, in June 2010; that was part of the project. Firefox for Android uses two processes, to improve UI performance. Bringing multiprocess Firefox to the desktop is a priority, but it's hard.
We're working on it, but it's a false dichotomy to suggest that we need to choose between improving our UI and improving our architecture. Indeed, if we choose one over the other, we lose. We have to do both.
If you can reproduce that behavior in Firefox 7 with all your extensions disabled, I'd very much appreciate if you filed a bug at http://bugzilla.mozilla.org./ I'll have a look if you CC me (jlebar).
Lots of memory in Firefox gets released on a timer -- in particular, the Javascript GC runs on a timer when the browser is idle, and the GC is responsible for collecting whole windows in Firefox -- whereas in Chrome, memory gets released as soon as you close a tab, since that kills a process. So it's not at all surprising that Firefox takes some time to release memory.
I recommend you try Firefox 7. It comes in ahead of Chrome in Lifehacker's memory benchmarks (for whatever that's worth). Keep in mind that a lot of extensions are low-quality and cause memory leaks or hog the CPU. This is something we're working on too, although it's hard, since we know how upset people get when we break their extensions...
Slashdot Mirror
Why not have bug fix patches for older releases? The problem isn't that these new releases are mostly just bug fixes, but that they're the ONLY release that's supported.
This is only a problem if
right?
In the first case, we rely on people testing our aurora and beta builds to find regressions. (Remember that Mozilla is a non-profit; we simply don't have the QA resources that Microsoft, Apple, and Google have, and even Google relies on community testing.) You can help by running Aurora.
In the second case...we try to make good changes, and we try to give people the option to revert their UI back to the old way, either through options in the browser or extensions. I understand that our track record here is mixed.
I don't claim it's perfect, but understand that we have limited resources. If we could, we'd love to support every version of Firefox we ever released forever. But the browser space moves quickly, and supporting just one release frees up engineering resources for things everyone wants, like MemShrink.
I believe 3.6 is still supported, I expect they'll pick another release for long(ish)-term support when they stop supporting that one.
This is a possibility, but there's a lot of debate within the organization as to whether we want to do this.
There are a variety of problems with supporting a version long-term. Among them:
See [1] for the long-term support proposal, but note that it hasn't yet been adopted in any formal sense.
[1] https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal
So, is it accurate to say that Firefox 9 is really something around 4.2.x or 4.3.x under standard numbering?
Yes, pretty much. Which actually a big part of the complaint: Firefox uses version numbers very differently from the way they are commonly understood.
Understand that our development process is unlike most other projects'. Like Chrome, we have three development versions in flight at once (nightly/canary, aurora/alpha, beta), and when we release, we promote nightly to aurora, aurora to beta, and beta to the release. In the X.Y model, the assumption is that you have only two versions in flight at once: X.(Y+1), which contains bugfixes, and (X+1).0, which contains new features.
Because our development model is so different, the X.Y numbers don't make much sense. You could call it 4.2, 4.3, and so on, but because every release is equal, when do you increase the major version number? When you feel like it?
Maybe you disagree with our release process. That's a fair criticism; it's not perfect. We can argue about the release process in a separate thread. But the version numbers follow logically from the process, I think.
1. Why the hell would that not be hard-coded to "Hell no, do not ever track me!".
See http://blog.mozilla.com/privacy/2011/11/09/dnt-cannot-be-default/
Are they addressing the outstanding bugs that came with the new features in version 8?
These are the bugs fixed for FF 8. And these are the bugs fixed for FF 9.
Please stop releasing new versions of firefox and fix the version you have
You do understand that the new releases have bug fixes, right? Probably the majority of patches going into any given release are bugfixes.
The main cause of random freezes should be fixed in the latest release, Firefox 8. If you're still seeing freezes, please file a bug and cc me (jlebar) and I'll follow up.
http://blog.bonardo.net/2011/09/30/is-your-firefor-freezing-at-regular-intervals
http://bugzilla.mozilla.org/
We'd love it if you filed a bug on this issue. A slashdot thread isn't the ideal place to try and figure this out.
http://bugzilla.mozilla.org/ Please cc ":jlebar" on the bug you file and I'll follow up.
Right now, b2g uses considerably less memory than Android. The difference is about 200mb on the phone I tested on.
Of course, b2g doesn't currently do much, and our memory usage will probably increase as we add more features. But we're paying close attention.
I did leave it open for a while till it stopped shrinking and I also clicked on "minimize mem usage".
FWIW the yahoo thing is still there despite the tab not being there. I did reopen that link again some minutes ago. How long do I have to wait till it goes away?
If you click minimize memory usage, everything should go away immediately. If you don't, I'm not sure how long you have to wait; five minutes (without touching Firefox) should be sufficient.
Are you running with extensions? It's probably an extension bug which is causing that yahoo compartment to stay there. If you can reproduce without any extensions, please file a bug and cc :jlebar. If not, then you may want to get in touch with the extension author (and you're welcome to file a bug and cc me anyway).
p.s. Is the Content Security Policy stuff gaining traction?
I have no idea whether people are using CSP, but apparently there's a WordPress plugin. :) http://people.mozilla.com/~bsterne/content-security-policy/wordpress.html
FWIW, it looks like you may not have left Firefox idle long enough to trigger a GC before you took this about:memory screenshot -- there's still a compartment for Yahoo Finance open. You can click "minimize memory usage" at the bottom of the page to force all our timers to fire.
To me what actually counts is whatever that would make the computer start to swap- even if the rest are small/tiny. That's the main thing right?
Right. This also means that peak memory usage -- which isn't what people on Slashdot usually talk about -- is just as important, if not more important, than memory usage after closing all tabs. It's when we're at our peak that we're most likely to cause swapping.
So Is it correct to say that Mozilla (even 7.0.1) often can't return some of the unused private bytes, and that can keep growing as the user opens and closes stuff?
I'm not sure if that growth is unbounded. I'm also not sure how much this growth affects our peak memory usage -- a lot of this fragmentation leaves gaps which we can fill in when you open new tabs.
But yes, it's correct that no version of Firefox uses as little memory after you close all tabs as it does when it first starts up.
From what I see, with Chrome opening and closing some windows/tabs usually frees up all the memory involved - the process just goes away returning the memory to the OS (and letting the geniuses in charge of the OS take care of fragmentation - not the browser's problem anymore ;)
Well, you can't fragment physical memory, because all pages are the same size! (Well, modern chips expose different-sized pages, but I'm not aware of this being used on any consumer device.) The heap fragmentation in this latest about:memory dump is pretty bad...
But architecturally, Chrome definitely has a leg up on us here. There's only so much we can do as-is. We're working to make architectural changes to match Chrome, but it's slow going.
So I see the 110MB "explicit". What's using the rest?
Let's see. Part is heap fragmentation. That's heap-committed - heap-used = 25mb. The rest is probably code. On my Linux machine, we load about 35mb of code (about half are shared libraries). 25mb + 35mb + 110mb = 170, which is very close to your 172.5mb of resident.
There are a lot of things here that we can improve. urlclassifier (phishing protection) does not need to use 20mb of memory; someone is working on this. We don't know where 1/3 of your memory is going (heap-unclassified); it's a slog, but we improve this a little in each version. 25mb of heap fragmentation is more than I'd like, and we're working to update our malloc library, jemalloc, to the newest version, which will hopefully improve this. I've also done some work to reduce the number of calls we make to malloc() in the first place, which has helped some.
As you can see, there's room for improvement, but we have to fix a number of small things to get a big change.
The vsize value [342mb] seems different from the windows reported VM size (about 170MB).
I think task manager may be counting only private bytes, but Firefox is counting everything in its virtual address space. On my Windows 7 VM, Firefox's vsize matches Process Explorer's virtual size column. If these don't match for you, that's probably a bug!
Didn't the Mozilla bunch claim the memory problems were fixed in version 3, 3.5, 3.6, 4, 5 and version 6?
As I recall, the claim was that memory problems were addressed in 3, 3.5, 3.6, 4, 5, and 6, not that your memory problems were fixed. It was before my time, but there was a concerted memory-usage effort in the 3 - 3.5 timeframe. You're right in that it's only in Firefox 7 that the results of our latest big memory push have seen the light of day. But that doesn't mean we didn't fix any problems in the meantime.
Go ahead blame me for not wanting to waste my time upgrading only to face the same problem.
In the amount of time it took you to write this post to Slashdot, you could have done each of these browser upgrades. We even save your tabs across upgrades. But like I said, my issue isn't that we lost your trust through bad PR -- that's our fault -- but rather that you claimed that memory usage is "still a problem" when you hadn't tried the latest version!
Is it supposed to still be using 180MB?
You can open up about:memory and see exactly where that 180mb is going, if you're curious. I'd love for our after-closing-tabs memory usage to be smaller, but with our current architecture, we're never going to be as small after you've used the browser as when you first start up. 180mb isn't abnormally high.
We've improved things in upcoming versions, too, but I'm not promising miracles. :)
I don't understand why people get so mad about this.
I'm sorry that you don't trust Mozilla to deliver on its promises any longer. I wish you'd check out the new version of Firefox, because we've put a lot of work into improving it. But hey, it's free software, and if you want to run a browser released in January 2010, more power to you!
The good news is that Firefox, Chrome, and Opera work on Windows, Mac, and Linux. You have options; nobody's making you use Firefox.
But maybe next time before you assert that memory usage is "still a problem", you could try the latest version. If you never upgrade your browser, you're never giving us a chance to fix anything.
Safari uses Preview internally, I believe. That's a C/C++/Objective C program, with all the security vulnerabilities that go along with that.
The news here is that Mozilla is trying to develop JavaScript which renders PDFs. So long as our JS engine is secure, this PDF reader would be secure. (And if the JS engine isn't secure, the whole browser isn't secure, so adding the PDF viewer isn't an attack vector.)
1) The poor performance and the extreme memory usage. Yes, this is still a problem. It's easily reproducible with fresh Firefox installations.
We have a whole team of engineers devoted to memory usage, and a second team devoted to performance. If you have issues you can reproduce, especially on a clean Firefox install, we'd love it if you'd file a bug. We can only fix problems we're aware of, and we're not aware of any huge leaks in the versions we're shipping.
http://bugzilla.mozilla.org/
From TFA:
5+ hours of CPU time for a single build, 25+ minutes of wall time, as measured on a workstation (dual-E5620 i.e. 2x quad-core 2.4GHz HT, with 24GB of RAM, no SSD).
Do you see car designers moving the pedals around to different places, or putting the headlight switch in the back seat because it looks "cool" there, or removing the steering wheel and putting in a tiller because they don't want to look "dated"?
Consider the Prius. The Prius's dashboard isn't in the usual place. It has a digital speedometer and no tackometer. You start it by pushing a button, not turning a key. You can unlock some models just by walking up to it. Oh, and Toyota just redid the body design this year.
Maybe you don't like the Prius. That's fine. But you'll grant me that lots of people do like it, despite these unnecessary changes. Toyota must be doing something right.
When a product gets to a certain level of maturity, it doesn't need any more change, unless it can be shown that that change really is a benefit.
I think what you mean is, when a product gets to a certain level of maturity, it doesn't need any more change, unless I really like that change. But the fallacy I keep hearing on Slashdot is that what I like is the absolute measure of what's good in the world.
If the changes we've made to the UI are really so heinous, a group of people will come together and either provide security updates to Firefox 3.6 until the end of time or maintain an extension which brings FF 3.6's UI to new versions. I don't think that would be so bad. To each his own.
What you need and for 2 years have claimed is 'too hard' (then you've got a problem -- you have a non-object oriented, monolithic core of code that is trying to emulate (run) objected oriented, separate tasks? You don't see that as being a fundamental design issue?
It is a fundamental design issue. That's why it's hard.
Even the linux kernel can split off sub-processes to do work -- it doesn't try to do everything in 1 event loop, certainly it should be easier to achieve this in a browser
We accept patches.
It's not that I mind 'UI Improvements' but as the guy you were quoting phrased it 'UI changes.' It is common to act like the two are synonymous but to me it seems like the vast majority of 'changes' are not 'improvements.' A lot seems to be tinkering for it's own sake. Which is fine in it's place. The world's defacto standard web-browser just is not the place for it.
I hear this all the time on Slashdot, and to be honest, I don't get it.
I understand when people don't like X or Y change, but the argument is often, as it is here, against change in general. Is the idea that Firefox should perpetually be stuck in the 2009? That Firefox 3.6 is the pinnacle of UI design, and that there's nowhere to go but down? Honest question.
To most people, the user interface *is* Firefox. We can't leave this static and expect to be relevant in three years. There are simply too many good ideas out there being implemented in other browsers. If you want a UI which will never change, use Lynx.
You're welcome to disagree with the design decisions which have been made, but I can assure you that they weren't made simply for the sake of tinkering with things. We have a team of really sharp designers who put a tremendous amount of thought into how Firefox looks and feels.
For those who don't RTFA:
One more note here for the benefit of Slashdot (hi!) and anyone else who's not clear on this issue or how our bug tracker works.
We made the decision not to make this configurable long, long ago, even before we WontFixed this bug in comment 59 (over a year ago itself). Accordingly the bug is closed because that reflects not only our current stance but the position we've had for a very long time.
This does not mean either that we will never listen to user feedback, or that we used to be listening on this bug but decided to stop. The issue is that our bug tracker is specifically about tracking what we consider to be bugs, not a general forum for feedback and debate on our design decisions. That means that in general (this bug included), we can and will decide not to address particular requests, and when we do, commenting on the closed bug is not going to make us change our minds. On the contrary, we will not hesitate to lock things down in the bug tracker precisely to prevent things from spiraling out of control or misleading people into sharing their feedback here instead of where it's helpful
We have other venues such as the chromium-discuss mailing list and our feedback forums where it is appropriate to share your opinions. The forums are a place where we are set up to track user feedback and surface the most critical issues to the team without impacting the productivity of us developers who are busy trying to make Chrome work better.
We don't promise we'll change our minds, but we're not hostile to you expressing your point of view. This is just not the correct forum to do so.
I just loaded up two gmail tabs, yahoo groups, and Facebook. According to Chrome's about memory, Firefox is using 262mb, and Chrome is using 288mb.
Have you tried disabling your extensions? Most memory leaks people see in FF are due to crappy extensions.
These problems all exist because Firefox stubbornly clings to the antiquated and idiotic notion of having all tabs and windows run in a single process. [snip] When is Firefox going to stop wasting time on useless UI changes and actually fix their architecture?
I think "stubbornly clings" is not supported by our actions. The multiprocess Firefox project is called Electrolysis. It's been going on for about two years now. We moved plugins to a separate process back in Firefox 3.6.4, in June 2010; that was part of the project. Firefox for Android uses two processes, to improve UI performance. Bringing multiprocess Firefox to the desktop is a priority, but it's hard.
We're working on it, but it's a false dichotomy to suggest that we need to choose between improving our UI and improving our architecture. Indeed, if we choose one over the other, we lose. We have to do both.
https://wiki.mozilla.org/Electrolysis
If you can reproduce that behavior in Firefox 7 with all your extensions disabled, I'd very much appreciate if you filed a bug at http://bugzilla.mozilla.org./ I'll have a look if you CC me (jlebar).
Lots of memory in Firefox gets released on a timer -- in particular, the Javascript GC runs on a timer when the browser is idle, and the GC is responsible for collecting whole windows in Firefox -- whereas in Chrome, memory gets released as soon as you close a tab, since that kills a process. So it's not at all surprising that Firefox takes some time to release memory.
Trust me, we're listening.
I recommend you try Firefox 7. It comes in ahead of Chrome in Lifehacker's memory benchmarks (for whatever that's worth). Keep in mind that a lot of extensions are low-quality and cause memory leaks or hog the CPU. This is something we're working on too, although it's hard, since we know how upset people get when we break their extensions...
http://lifehacker.com/5844150/browser-speed-tests-firefox-7-chrome-14-internet-explorer-9-and-more