Mozilla brings back 64-bit builds of Firefox for Windows(groups.google.com)
groups.google.com
Mozilla brings back 64-bit builds of Firefox for Windows
https://groups.google.com/d/topic/mozilla.dev.apps.firefox/DOihL2429NM/discussion
4 comments
> It still sounds like their focus really is not on 64-bit
It's a matter of priorities. 64-bit is important, but for almost all users, it isn't an immediate concern to use 32-bit on windows, nor would they get a big benefit to move to 64-bit bit there.
There are other things that the devs are focused on, that have more tangible immediate benefits. That's all it comes down to. At some point though I would imagine 64-bit would become higher priority.
edit: Regarding multiprocess, it is already used in FirefoxOS, for example. Enabling it on desktop would be hard because of all the existing addons, on mobile though it has been used for a while (the Android browser was multiprocess, now it is multithreaded, and the FirefoxOS browser is as I said multiprocess). Since most of the growth in the browser market today is in mobile (sales of desktop PCs actually declined this year), that is a forward-looking approach I would say.
It's a matter of priorities. 64-bit is important, but for almost all users, it isn't an immediate concern to use 32-bit on windows, nor would they get a big benefit to move to 64-bit bit there.
There are other things that the devs are focused on, that have more tangible immediate benefits. That's all it comes down to. At some point though I would imagine 64-bit would become higher priority.
edit: Regarding multiprocess, it is already used in FirefoxOS, for example. Enabling it on desktop would be hard because of all the existing addons, on mobile though it has been used for a while (the Android browser was multiprocess, now it is multithreaded, and the FirefoxOS browser is as I said multiprocess). Since most of the growth in the browser market today is in mobile (sales of desktop PCs actually declined this year), that is a forward-looking approach I would say.
https://wiki.mozilla.org/Electrolysis#Status (take note of the then-future dates)
http://www.2ality.com/2011/12/firefox-electrolysis-on-hold.h...
I wondered how they went so far off the rails and let this fall by the wayside, not even updating the project status.
http://www.2ality.com/2012/02/servo.html
Mozilla had to find a replacement for C++ and chose Rust.
. . .
[Rust] Release 0.2, 2012-03-29:
I'm trying to think of a nice way to say that it's maybe not a good idea to invest in inventing a new language instead of focusing on your flagship product.
http://www.2ality.com/2011/12/firefox-electrolysis-on-hold.h...
I wondered how they went so far off the rails and let this fall by the wayside, not even updating the project status.
http://www.2ality.com/2012/02/servo.html
Mozilla had to find a replacement for C++ and chose Rust.
. . .
[Rust] Release 0.2, 2012-03-29:
I'm trying to think of a nice way to say that it's maybe not a good idea to invest in inventing a new language instead of focusing on your flagship product.
First, Rust is a handful of people working on a research project.
Electrolysis was "put on hold" because there were better ways to make Firefox a more responsive browser, now. That's projects snappy and supersnappy. See https://wiki.mozilla.org/Performance/Snappy and http://taras.glek.net/ and https://bugzilla.mozilla.org/show_bug.cgi?id=718121 -- the final bug being what I think will make Firefox a great browser again.
Electrolysis was "put on hold" because there were better ways to make Firefox a more responsive browser, now. That's projects snappy and supersnappy. See https://wiki.mozilla.org/Performance/Snappy and http://taras.glek.net/ and https://bugzilla.mozilla.org/show_bug.cgi?id=718121 -- the final bug being what I think will make Firefox a great browser again.
I thought people want electrolysis or 64 bit because they have so many tabs open that they run out of address space; no amount of snappiness will fix that problem.
That's probably a valid concern, but it's at best a fringe requirement, I would suspect, compared to the huge number of people who would want a snappier browser. Electrolysis provided some benefits here, because less parts of the browser would run in the same processes and threads.
Unlike the quip about working on Rust above, this is a matter of prioritization of effort. I would not qualify myself as experienced enough to make the decisions to run a project as large and with as many users as Firefox, but I don't think that Mozilla is wrong here.
Unlike the quip about working on Rust above, this is a matter of prioritization of effort. I would not qualify myself as experienced enough to make the decisions to run a project as large and with as many users as Firefox, but I don't think that Mozilla is wrong here.
I and about half of the people I know regularly test the limits of how many tabs they can keep open. The other half can't imagine doing so. I suspect this is a sharp bifurcation of use case that the project leads have found themselves on one side of, not a "fringe requirement."
The Memshrink project is the one geared towards the lowering of memory consumption for Mozilla projects (Firefox, Thunderbird, and Boot2Gecko mainly).
New programming languages have been the downfall of many a great tech company, but not nearly as many as "focusing on your flagship product" to the exclusion of a changing world.
Rust, Typescript, Go, Dart are all awesome. I'd love to see any one of them change the world of development.
Rust, Typescript, Go, Dart are all awesome. I'd love to see any one of them change the world of development.
Electrolysis also broke compatibility with many Firefox add-ons. The code is not dead, however. It's used in B2G.
Single process per tab is heavyweight, and is the reason why Chrome uses more memory than Firefox once you have a few tabs open.
Very few people actually hit the point where 64-bit memory is useful to them, and thus it's not a focus for Firefox at the moment.
Very few people actually hit the point where 64-bit memory is useful to them, and thus it's not a focus for Firefox at the moment.
It should be. x64 has speed improvements (due to quirks), and Win64 has important security improvements.
From the article:
> At this point, the Mozilla project does not have the resources to actively support this use case.
http://en.wikipedia.org/wiki/Mozilla_Foundation#Financing
$300 million a year, and they can't afford to support Win64, the predominant platform, of an open source project? Someone needs to get in there and start cleaning house.
From the article:
> At this point, the Mozilla project does not have the resources to actively support this use case.
http://en.wikipedia.org/wiki/Mozilla_Foundation#Financing
$300 million a year, and they can't afford to support Win64, the predominant platform, of an open source project? Someone needs to get in there and start cleaning house.
(($300m / numberOfUsers) * numberOfExtremeUsers) / numberOfEngineersRequired / numberOfYearsRequired
Don't have to be an extreme user to take advantage of the features above, they benefit everyone. Nor would it require years, it already works fine (has for years and on every other OS) ... just could use a little optimization.
> Single process per tab is heavyweight, and is the reason why Chrome uses more memory than Firefox once you have a few tabs open.
Very true. One has to experience it before it hits you. I've completely stopped using Chrome/Iron now.
Very true. One has to experience it before it hits you. I've completely stopped using Chrome/Iron now.
It's been a while since I've used Firefox as my primary browser, but in my experience, long running use of Firefox used way more memory than Chrome. Because of its process per tab architecture, Chrome has always been able to clean up unused memory much better than Firefox. To me that's more important than saving memory on individual tabs, because I leave my browser open for weeks at a time.
Firefox isn't quite as good as Chrome when it comes to retrieving memory, but it's much better than it used to be. And it's vastly better than Chrome when you have those tabs open:
http://techlogon.com/2012/09/21/review-of-firefox-chrome-and...
I have no idea what that link is supposed to be demonstrating. It doesn't say how they measured memory usage (private working set, address space, ouija board stacks?) and doesn't share any of their data sets. It's an arbitrary set of claims devoid of substantiating context, and as someone who has measured this before, it doesn't appear to align with reality.
The fact is that single process versus multiprocess carries different tradeoffs with respect to memory. A single process has an advantage in the short run, in that it will consume less memory initially. However, in terms of private working set memory across multiple tabs you're simply not going to see anything like the 2x claimed in that link, given that much of the address space maps to shared pages. So, most likely the authors just weren't properly measuring memory usage per-browser.
On the flip side, a multi-process architecture has its own strong advantages for memory consumption. Any complex, long-running application is going to have to contend with memory leaks and fragmentation, which exert increasing memory pressure over the life of an active process. This gets even more painful when considering the multitude of heaps in your average browser, chrome layers written in Web technologies, and (iirc) Firefox using a non-moving, non-generational GC. Whereas a multi-process browser has a vastly cleaner solution to all of that: it simply disposes of an entire address space (including all fragments and leaks) when it's done with a rendering context.
Now, I don't want to undermine the really great work that the Mozilla guys have done addressing leaks and fragmentation, with things like cycle detection, JavaScript compartments, and various detection and analysis tools. However, the simple fact is that users who keep their browsers open for many hours, days, or weeks at a time are generally going to suffer from these issues more under Firefox than Chrome or protected mode IE.
The fact is that single process versus multiprocess carries different tradeoffs with respect to memory. A single process has an advantage in the short run, in that it will consume less memory initially. However, in terms of private working set memory across multiple tabs you're simply not going to see anything like the 2x claimed in that link, given that much of the address space maps to shared pages. So, most likely the authors just weren't properly measuring memory usage per-browser.
On the flip side, a multi-process architecture has its own strong advantages for memory consumption. Any complex, long-running application is going to have to contend with memory leaks and fragmentation, which exert increasing memory pressure over the life of an active process. This gets even more painful when considering the multitude of heaps in your average browser, chrome layers written in Web technologies, and (iirc) Firefox using a non-moving, non-generational GC. Whereas a multi-process browser has a vastly cleaner solution to all of that: it simply disposes of an entire address space (including all fragments and leaks) when it's done with a rendering context.
Now, I don't want to undermine the really great work that the Mozilla guys have done addressing leaks and fragmentation, with things like cycle detection, JavaScript compartments, and various detection and analysis tools. However, the simple fact is that users who keep their browsers open for many hours, days, or weeks at a time are generally going to suffer from these issues more under Firefox than Chrome or protected mode IE.
"This gets even more painful when considering the multitude of heaps in your average browser, chrome layers written in Web technologies, and (iirc) Firefox using a non-moving, non-generational GC. Whereas a multi-process browser has a vastly cleaner solution to all of that: it simply disposes of an entire address space (including all fragments and leaks) when it's done with a rendering context."
You're overstating the impact of JS here. JS memory is allocated in large "chunks" in Firefox. This minimizes external fragmentation. When a rendering context is destroyed, all of the chunks are immediately destroyed with it; because of compartments, we know that there are no chrome JS objects interspersed with the content JS objects, so we can just destroy these large chunks. So the amount of JS-related fragmentation resulting from closing rendering contexts is minimal in practice.
Regarding chrome layers written in Web technologies, this is somewhat orthogonal, since in all browsers chrome allocations stick around for the lifetime of the browser. C++ code has no compaction story, and, unlike JS, it has no reasonable path to achieve compaction in the future.
You're overstating the impact of JS here. JS memory is allocated in large "chunks" in Firefox. This minimizes external fragmentation. When a rendering context is destroyed, all of the chunks are immediately destroyed with it; because of compartments, we know that there are no chrome JS objects interspersed with the content JS objects, so we can just destroy these large chunks. So the amount of JS-related fragmentation resulting from closing rendering contexts is minimal in practice.
Regarding chrome layers written in Web technologies, this is somewhat orthogonal, since in all browsers chrome allocations stick around for the lifetime of the browser. C++ code has no compaction story, and, unlike JS, it has no reasonable path to achieve compaction in the future.
[deleted]
We're only talking about 64-bit builds of Firefox for Windows. Firefox builds for Mac OS X and Linux are already 64-bit. Chrome is 32-bit on both Windows and Mac OS X.
From what I have read, it is lack of a maintainer since the current developers are concentrating on other features. The 64-bit support problem is also only on Windows, and one of the dis-incentives is lack a of 64-bit plugins.
Lack of plugins is a benefit in my world! :-)
Seriously, there are other tangible security benefits to 64 bits as well. For example, ASLR is going to have more bits with which to randomize DLL base addresses.
Seriously, there are other tangible security benefits to 64 bits as well. For example, ASLR is going to have more bits with which to randomize DLL base addresses.
Most importantly, it seems that there are users who regularly run into the 4GB memory limits of 32-bit builds. These users often have hundreds or even thousands of tabs.
Wow, and I thought I was ADD!
Wow, and I thought I was ADD!
It still seems to me like, if you have thousands of open tabs, it is your browsing habits that need to change- not Firefox. How often will you even look at the 1,925th tab?
Firefox has a perfectly good bookmark system.
Firefox has a perfectly good bookmark system.
I would say that if lots of users are using tabs as placeholders in this way, and I personally know a lot including myself, then it's evidence of the bookmarking system being a bad or poorly designed solution for this problem. Bookmarks are treated as long term archives for links, and more trouble to manage, curate, and organize than is necessary for ephemeral sites you'd like to read later.
Some people mention "read it later" features, which I personally use. Safari has read lists, but I would argue these are also poorly understood and under utilized by most people.
For me, I believe a solution is something like "read it later", but lighter weight, easier to manage, and more integrated so that it doesn't just end up being another out of sight, forgotten backlog of things you wish you had read.
Some people mention "read it later" features, which I personally use. Safari has read lists, but I would argue these are also poorly understood and under utilized by most people.
For me, I believe a solution is something like "read it later", but lighter weight, easier to manage, and more integrated so that it doesn't just end up being another out of sight, forgotten backlog of things you wish you had read.
Tabs are too ephemeral; I have a hybrid of the two. I use tabs for things I will read later but won't care about in a week. Things that I wish to store long-term are bookmarks, and tabs that get too old are either culled or converted to bookmarks.
As someone who often has more then a few tabs open, I use it primarily as a way of saving pages to read later (especially with HN links). I find I would never actually read bookmarks, but having tabs means I will get around to reading them. Mozilla did a presentation on this kind of use-case recently it recently, https://speakerdeck.com/bcg/saving-for-later.
I believe that as developers, it's our role to give the users what they want and not judge them.
Except in cases where we really do know better and the user is likey just digging themselves deeper (e.g., creating security problems). Then they deserve a warning.
If you were WalMart manager and someone came in and a schoolteacher bought your entire inventory of crayons and wanted more, would you not order more for them? Or would you say "you need to change those kids' habits so they aren't breaking all those crayons".
Except in cases where we really do know better and the user is likey just digging themselves deeper (e.g., creating security problems). Then they deserve a warning.
If you were WalMart manager and someone came in and a schoolteacher bought your entire inventory of crayons and wanted more, would you not order more for them? Or would you say "you need to change those kids' habits so they aren't breaking all those crayons".
On my desktop (using Chrome), I have about 50 tabs open, which is apparently using about 3 gigs of memory (EDIT: and certainly even more of the address space when you count memory mapped files). Granted, I have heard that Firefox uses less memory than Chromium these days, due to the multi-process overhead, but nonetheless I imagine those numbers would be somewhat similar on Firefox.
Thousands of tabs may be a fringe use case, but clearly, you can approach the 32-bit address space limit under much more sensible loads.
Thousands of tabs may be a fringe use case, but clearly, you can approach the 32-bit address space limit under much more sensible loads.
My experience with 50 tabs open in Firefox and Chrome is that Chrome uses about 75% more memory. You can test this yourself instead of guessing. Also, people with 50 or more tabs open represent less than 1/4th of one percent of Firefox users and I'd imagine that's roughly the same for Chrome and IE so I think it's a stretch to call that a "sensible load". 50 tabs is an extreme load and Firefox handles it better than Chrome in my experience.
http://techlogon.com/2012/09/21/review-of-firefox-chrome-and... seems to show that Chrome uses about twice as much memory when opening a load of tabs.
It isn't "perfectly good" though, is it? As far as I'm concerned, bookmarking is an unsolved problem. Every system in existence sucks.
Pocket, Instapaper, etc. are nice enough for reading things later, but they don't handle the use case of bookmarks as a reference system. I'm not aware of anything which does that well.
Pocket, Instapaper, etc. are nice enough for reading things later, but they don't handle the use case of bookmarks as a reference system. I'm not aware of anything which does that well.
> It still seems to me like, if you have thousands of open tabs, it is your browsing habits that need to change- not Firefox.
"You're holding it wrong."
Decisions like these make software that's unusable for some people. It's the Apple Syndrome: You either obey the One Steve Jobs Way or you go elsewhere. Let's leave the Apple Syndrome to Apple, and make software everyone can use.
"You're holding it wrong."
Decisions like these make software that's unusable for some people. It's the Apple Syndrome: You either obey the One Steve Jobs Way or you go elsewhere. Let's leave the Apple Syndrome to Apple, and make software everyone can use.
I'm not advocating the "One Way". Rather, I gather the thousand-tabs users are fringe. They are welcome to use it that way if they like. But when it comes to development; is it better to spend developer time on making Firefox a lot better for 1% of users, or a little better for 95% of users?
Because we are the ones that use FF? ;-)
Halfway joking here but I think perfectly ordinary people who just use a few tabs at a time tends to just use whatever thay get their hands on, -IE on Windows or Safari on Mac.
This means there is already a bias here: Those who use FF use it anyway because there is no alternative that has Scrapbook extension (offline browsing w/searchability), tree tabs (for automatic mind mapping) that also handles 100-200 tabs in a good way. (Read up on David Allen on using your memory for real work not to remember addresses and tasks for why some people find this useful.)
Halfway joking here but I think perfectly ordinary people who just use a few tabs at a time tends to just use whatever thay get their hands on, -IE on Windows or Safari on Mac.
This means there is already a bias here: Those who use FF use it anyway because there is no alternative that has Scrapbook extension (offline browsing w/searchability), tree tabs (for automatic mind mapping) that also handles 100-200 tabs in a good way. (Read up on David Allen on using your memory for real work not to remember addresses and tasks for why some people find this useful.)
We have data on Firefox tab usage. It's not at all what you have suggested. Most Firefox users never have more than 5 or 6 tabs open at a time. The median is about 3 tabs. See http://66.43.220.232/james/mozilla-challenge.html for some slightly out of date but not too far off data. (Note, these are the "geeks" that opted in to our study so it's likely skewed a bit to the heavier tab users.)
Wow, thanks for taking the time. Happy to know that ordinary people use FF as well.
We build products for as many people as we can. That being said, we do not have infinite resources so we are sometimes forced to make trade offs. The median Firefox user has 3 tabs open at any given time. The 90% user has fewer than 10 tabs open.
Great to see them listening to feedback there!
Can someone explain me why it's so hard for Mozilla to have a x64 build? Why is the core of Firefox not platform independent? I just don't get it.
The code works fine (enough); that's why they will (now) ship nightlies of Win64 builds. The problem is two-fold: 1) They don't want their engineers to spend time fixing Win64 errors, and rely solely on people who care a lot about Win64 (thanks, m_kato!) to clean up after the "normal" people. 2) For some silly reason, they have nowhere near enough machines (and people to run them) to properly support development. This is even ignoring Win64 builds - multiple checkins will typically share an integration build, and checkins frequently has to stop to back out a bad change and wait for the machines to catch up to make sure the problem is fixed. They have a system (try servers) to fake-checkin to run the tests to make sure things are good - but due to resource constraints people are encouraged to reduce the coverage; heck, they have a "high score board" to shame the heavy users.
Having it is easy (which is what they've decided to do in this compromise), it's supporting it that's hard.
Does anybody know if they are at least working toward separate processes per tab? Continuing to focus on single process 32 bit seems like an absurd strategic move.