This doesn't work with WPO/PGO, which makes it useless for the purposes of this post.

We've looked into this, but the potential for incompatibilities between the CRT headers and the implementation is worrisome. It also hasn't been a real priority to this point because it wasn't a big deal to ship the VC8 CRT alongside Firefox. (And, in fact, until recently, it was pretty necessary because we were building a custom CRT from source so we could patch it to replace the default malloc.)

Do you have a source to back that up? I've never been able to find any information saying that Microsoft compiles their OS libraries with PGO. In fact, in their "Debugging in the (Very) Large" paper, they state that they even turned off frame-pointer omission, since it caused more headaches and didn't give them a noticeable speedup.
http://research.microsoft.com/apps/pubs/default.aspx?id=81176

Raymond Chen disagrees with you:
http://blogs.msdn.com/b/oldnewthing/archive/2005/06/01/423817.aspx
citing:
http://support.microsoft.com/default.aspx?scid=889654

I really wanted this to work, but it doesn't actually work in combination with PGO:

(with the VC2008 32-bit compiler)
$ cl -GL -Fotest.obj -c test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.cpp

(with the VC2008 64-bit linker)
$ link -MACHINE:X86 -LTCG -OUT:test.exe test.obj
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

fatal error C1905: Front end and back end not compatible (must target same proce
ssor).
LINK : fatal error LNK1257: code generation failed

Except what BZ just said is that you pretty much need all of those core pieces to start the browser anyway, so splitting them out into separate modules just makes the browser start more slowly.

Also, cross-module optimization does help quite a bit. Microsoft's PGO optimizer is able to do crazy stuff like speculative virtual call inlining, which is a big deal on a large C++ codebase like Mozilla.

Uh, what? Visual C++ produces better optimized code than GCC in almost all cases, especially when you toss PGO into the mix. Firefox runs just fine on most people's systems. There are plenty of pathological cases on people's systems that make it perform poorly: poorly-written extensions, poorly-written antivirus software that hooks into our process, horrible disk fragmentation, etc. The list goes on and on, we've seen all of these things in bug reports from users experiencing poor performance. If you're experiencing poor performance, I'd encourage you to file a bug (you can even link the bug here, and we can take a look). Unless you're running on some ancient hardware it's possible there's a reasonable explanation for your situation that has nothing to do with the compiler we're using.

Your last statement reads like a non-sequitur. What other large open-source project that's comparable to Firefox is producing Windows binaries with GCC that you can compare performance? Unless it's a web browser, comparing performance is like comparing apples and moon rocks.

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.

Nope, the issue is still present in Visual C++ 2010. We're planning on switching to that soon, but we either have to work around its lack of support for Windows 2000 / Windows XP pre-SP2, or declare those platforms (and a few million users) unsupported.

This is an advanced setting that we don't expect users to tweak. The default value should work for most people. Here's a decent test: if you have to go to about:config to change a setting, it's not something we want normal users to touch, so talking about usability at that point is a bit silly. The most usable software just does the right thing and doesn't require users to change setttings.

Conveniently Mike is also the Debian Firefox package maintainer, so I'd expect him to apply as much of his work as possible to those packages. That's not to say that Debian's Firefox builds will be as fast as the official Mozilla builds, since Debian has other priorities that may conflict.

Intel does have ICC, but it's kind of expensive, and it's picky in different ways than GCC/VC++, so it means fixing up things across the entire codebase to even get it to work. I was able to build our JavaScript library on OS X with ICC at one point without a huge amount of hassle, and it was a decent speedup back then (but Apple's GCC is ancient). Using it on Windows would probably be a PITA in terms of amount of work to even compare performance.

There were actually several GCC bugs that had to be fixed in order for us to use PGO. Thankfully Mike has a good working relationship with GCC maintainers, and he upstreamed all necessary patches, so everybody wins.

Not really true, we actually built our Linux builds with -Os (optimize for space) up until this change, where we switched to -O3 (optimize for speed) + changed from GCC 4.3 to GCC 4.5 and also enabled profile-guided optimization at the same time. The end result is a pretty nice performance win and not much disk space change.

Windows builds of Firefox didn't get profile-guided optimization until Firefox 3 (2008), so it's only about 3 years behind. Actually I think Firefox 1.0 might have been shipped with PGO on Linux, but I wasn't directly involved in that release so I can't recall. Mike had to chase down a number of bugs in GCC in order to make it work again, which is nice because it benefits all GCC users. GCC developers are using Firefox as a testcase for further optimizations in GCC 4.6 (like LTO), so we should hopefully be able to use those when it's released.