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

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.