Slashdot Mirror
Firefox Too Big To Link On 32-bit Windows
An anonymous reader writes "Firefox has gotten so large that it cannot be compiled with PGO on a 32-bit linker anymore, due to the virtual memory limitation of 3 GB. This problem had happened last year with 2 GB, which was worked around by adding a/3GB switch to the Windows build servers. Now the problem is back, and things aren't quite that simple anymore."
This only affects the inbound branch, but from the looks of it new code is no longer being accepted until they can trim things from the build to make it work again. The long term solution is to build the 32-bit binaries on a 64-bit system.
You're right. As anyone who's read C++ FQA by Yossi Kreinin might guess, C++ itself could be one of the culprits.
Yes, but you can get a 32->64 cross-GCC toolchain easily. You can't get one of those from Microsoft, so you're stuck with a maximum of 4GB of address space if you run the 32-bit toolchain on a 64-bit Windows system.
I'd already have switched to Chrome if not for FF's Live Bookmarks. Reading a bunch of different sites, multiple times a day it makes for an easy scan of story titles to see if anything is worth looking at. Otherwise I'd switched long ago and was sad Chrome didn't come with it. I don't want to manage a dedicated app.
I can't speak to Firefox specifically, but in my hands, for my project, VC++ produces code that is VASTLY superior to gcc. With gcc, I can often get significant speedup by hand-optimizing code; with VC++, my bog-simple code gets automatically optimized better than my most aggressive manual efforts. Like it or not, Microsoft has the currently best compiler.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Looks like they're having similar problems:
https://code.google.com/p/chromium/issues/detail?id=21932
"When information is power, privacy is freedom" - Jah-Wren Ryel
Then I find that more worrying than anything. The firefox code is literally so bad that not only do they have to do profile-guided optimisation but must have an optimal compiler with all the options turned up in order to get it to run like the stunned sloth that it does on my systems?
It just reeks of horrendous code. Makes me wonder what the hell all those other large open-source projects are doing that's so much better than the Firefox code that they can outperform it using "only" the sub-optimal gcc.
I think you miss the subtext that some of us have. If you HAVE to enable PGO in order to get a decent speed out of your binary in the first place (and that's the ONLY way you think you get that increase), then your code isn't that great in the first place (i.e. you are using lots of inefficient methods on the most-used paths of your code).
The problem isn't DIRECTLY related to the size/quality of the codebase but the fact that they don't even CONSIDER turning off PGO because of the performance drop means they have no idea how to tune the underlying code without using PGO (and PGO-optimised code will NOT necessarily result in the best possible code for any particular user at all!)
That still shows poor design.
Much of FF's bloat is due to added features only a subset of users want. What FF should do is what the Linux kernel does. And that is to make lots of parts be separately loaded modules. Unlike the kernel, these can easily be dynamically loaded by the program itself as needed, and even unloaded when not needed. Then stuff a given user never uses would never be loaded (it would just sit in the filesystem as a .so file somewhere). These modules would all be separately compiled (from the common headers that describe interfaces), and ... this is important for this issue ... separately linked.
now we need to go OSS in diesel cars
The other day a coworker walked in to ask me what I use as my browser. I said Safari. He asked why not Chrome. I told him I had Chrome installed, and used it occasionally. I couldn't remember exactly why I prefer Safari, so I started both of them up. Safari was done launching in a couple of seconds, almost before I had time to click on Chrome. We continued our discussion of why I don't use Chrome while waiting for it to launch.
Checking the .app size... Safari is 35 MB, Chrome is about a quarter of a gig.
Nope. It is the MS linker problem. It's not about memory usage, it's about stupidly memmapping ALL of the input files during startup. So it's very simple to check if you may have a problem: add up the size of all the .obj files. If it's above 1-1.5G or so, it won't fit as linker needs address space for its own transient data and you need to boot with the /3g switch. If it's above 2G or so, then even the /3g switch won't help you -- you need a 64 bit host.
A successful API design takes a mixture of software design and pedagogy.