

Gecko is too big - Firefox development stalls over code linking issue - farzul
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/c0b1d383f9a8ca63#

======
khuey
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.

------
justinschuh
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.

~~~
nonane
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?

~~~
khuey
There is no x64->x86 cross compiler with MSVC, so if you want to produce i386
binaries you have to fit under 4GB of memory no matter what.

~~~
yuhong
True, but you may be able to compile with the x86 compiler and link with the
64-bit linker.

------
zobzu
the issue is XUL, not Gecko-Gecko per se. tho I agree - XUL while providing
this cool extensibility, gets huge.

just take a look at Fennec's nightly. what they did is wipe XUL. thats right.

\- It's using Native UI, aka, it's using whatever the OS provides (here,
Android's UI). and just runs Gecko in it.

\- It breaks addons touching XUL.

\- It uses very little memory in comparison

\- It's freaking FAST. Puts Chrome, Opera, you name it to shame. Yes, really!

\- UI _NEVER_ lags. Thats right, fixes that too.

\- Oh and it does support Flash for Android this time.

Then again, its a pretty early nightly of a whole new Fennec so there _are_
bugs and missing functionality.

Why I'm saying that? Well, despite the addons issue I'd wish for at least such
an experimental version for Win/OSX/Linux. It's just that good.

~~~
jruderman
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.

