Heh, I guess I should have known better than to have fun with the title of my email.
This really isn't that interesting. Doing whole program optimization on a large codebase takes a fair amount of memory. We've exceeded virtual address space limits on MSVC 2005's linker a couple times in the past, and gotten past it before. We'll hack around it for the moment, and we're in the process of replacing our toolchain with a more modern version.
I'd note two other things:
1) The amount of binary code we ship isn't actually that high. "Libxul" (meaning Gecko, the networking stack, XPCOM, etc) is only about 16 MB of compiled code. The JS engine, crypto libraries, sqlite, etc, add a couple more MB. Compare this to chrome.dll or mshtml.dll and I think you'll see that we stack up pretty favorably.
2) Code size is actually about the least interesting metric of performance/bloat/what have you that there is. A lot of the code sits idle most of the time (think things like video codecs, character conversion code for random charsets you've never heard of) and can be swapped out (or not even loaded into RAM).
tl;dr: hit a compiler/linker bug, will have it fixed in a day or two.
That is a frighteningly sensationalist and misleading title; there's no evidence in this thread that Gecko is too big or development is stalled. The fact is that many large projects now hit 32-bit ceilings when compiling on Windows. For example, Chrome has had to repeatedly split and restructure VS projects to stay under the memory caps.
I disagree that there is no evidence in the thread that Gecko is too big. The "Gecko is too big" in the title is directly from the thread, started by a Mozilla developer.
The evidence that development has stalled is the fact that the tree for landing code changes has closed. SPDY, recently announced here, has been, or is being considered for, removal to relieve code size.
These are slightly sensationalist ways of phrasing the following facts:
* libxul hit linker limits on 32-bit Windows builds with profile guided optimization enabled, as it did a couple of years ago. PGO uses a lot of memory, but it's how we deliver on Windows, so it's important.
* mozilla-central and mozilla-inbound were temporarily closed to avoid further build failures whilst the issue was explored. Other trees (try, services-central, etc. etc. etc.) remained open.
* some recent large changes to libxul were backed out in order to relieve pressure on linking.
* mozilla-central is now open for landings that aren't libxul-related, apart from those to trim it down. JavaScript and other landings continue unabated.
So what you're saying is that Gecko (libxul) has gotten too big, and that development of libxul stuff (Gecko) has stalled until it has fixed. How is my title sensationalist? For those wondering, the bug where this is discussed is: https://bugzilla.mozilla.org/show_bug.cgi?id=709193
To be clear, the only thing that's "stalled" is integrating large pieces of code into our nightly builds. People are certainly still working on developing their bug fixes/features/etc.
That's why I said "stalled" and not "halted" or "stopped". I'm surprised the discussion is around the wording of the title, half of which is your choice of wording, rather than the content. It's an interesting thing that a major open source development effort has hit a road bump in development, and the steps to solve it are interesting.
What prevents these projects from building on a 64bit OS with a 64bit compiler? Isn't that the simplest solution to getting rid of the ceilings rather than to continually restructure?
I'm guessing they have to switch the build toolchain, and its automated, so they have to make a decision before asking IT to do so. (again, its a guess)
The funny thing is that the defense of Mozilla here is coming from a Googler who works on Chrome. So, the fact-free vitriol you generally spew is even less appropriate in this case.
Fennec doesn't use XUL for primary UI, but it's still compiled with XUL enabled.
Fennec's improved launch speed is partly due to the order in which components are loaded: the primary UI can appear before the layout engine is ready.
Compiling without XUL would shave some size off the binary, but probably not a whole lot. Most of the code involved in rendering XUL is the same code that renders HTML.
I agree. A non-XUL version of Firefox would be excellent. The mobile work in this area shows great promise.
Unfortunately support for embedding Gecko has been woeful, making experiments in this area difficult. The lack of an embedding story for Gecko is a big reason for it losing ground to WebKit in my opinion.
Another great fact of Fennec (Aka Firefox Mobile) - the latest version is the highest scoring tablet/mobile browser on html5test.com, scoring the same as Desktop Firefox.
This really isn't that interesting. Doing whole program optimization on a large codebase takes a fair amount of memory. We've exceeded virtual address space limits on MSVC 2005's linker a couple times in the past, and gotten past it before. We'll hack around it for the moment, and we're in the process of replacing our toolchain with a more modern version.
I'd note two other things: 1) The amount of binary code we ship isn't actually that high. "Libxul" (meaning Gecko, the networking stack, XPCOM, etc) is only about 16 MB of compiled code. The JS engine, crypto libraries, sqlite, etc, add a couple more MB. Compare this to chrome.dll or mshtml.dll and I think you'll see that we stack up pretty favorably. 2) Code size is actually about the least interesting metric of performance/bloat/what have you that there is. A lot of the code sits idle most of the time (think things like video codecs, character conversion code for random charsets you've never heard of) and can be swapped out (or not even loaded into RAM).
tl;dr: hit a compiler/linker bug, will have it fixed in a day or two.