I've compiled the latest Firefox source (nightly) with various gcc compiler optimization options, compared to the "default" moz build options on my platform. This is not a comprehensive test, but merely gives some ideas of where the "best bang for the buck" is. I ran the Sunspider benchmarks three times for each build instance. My box is a single CPU core2 system with 4GB RAM. The compiler options used were as follow:

-Os -march=core2 -mtune=core2
-O2 -march=core2 -mtune=core2
-O3 -march=core2 -mtune=core2
-O2

The last is the default optimization options on my platform, which is what I call the "Moz" build. The "core2" options turns out to have little effect (1.01x - 1.03x at the most), but "-O3" vs "-O2" has significant impact ("-O3" always generates the fastest browser on my platform). And of course, the new JIT compiler is very fast. For now, all I have is this little screen shot of a table I made with the results, I'll convert this to a proper HTML table in my copious spare time.

The way to read this table is a little bit complicated, but pick a row (e.g. "O3 + JIT") and follow it to the column you wish to compare it to (e.g. Moz + JIT), and you see that the "O3 + JIT" build is 1.10x faster. The conclusions I can make is that it's always best to optimize as much as possible, optimizing for size doesn't makes sense on these modern CPUs (core2), for the Firefox code base. And JIT is always vastly superior.

As a side note, the build with the "-Os" options (optimize for size) was incredibly unstable with the JIT compiler enabled. It took me many, many runs to get it to complete three benchmarks without hanging.

Recently I've been working on porting a very large (and obsolete) system to a modern Linux platform. This has been rather painful, particularly since the code has a million and one compiler warnings (when compiled with g++ -Wall). In particular, one class of warnings was annoying the hell out of me:

foo.cc: In constructor ‘Foo::Foo()’:
foo.cc:34: warning: ‘Foo::loki’ will be initialized after
foo.cc:33: warning:   ‘int Foo::leif’
foo.cc:41: warning:   when initialized here

This might not seem like a big deal, but when we're talking about 30 or more members that needs to be initialized, and they are completely out of order, it quickly becomes annoying to figure out the correct order. So, I hacked up gcc a bit, to introduce a more helpful warning. With this patch, I now get something like this instead:

foo.cc: In constructor ‘Foo::Foo()’:
foo.cc:34: warning: ‘Foo::loki’ will be initialized after
foo.cc:33: warning:   ‘int Foo::leif’
foo.cc:41: warning:   when initialized here
foo.cc:41: warning: Correct initialization order is:
foo.cc:44: warning:   Foo::leif
foo.cc:44: warning:   Foo::loki
foo.cc:44: warning:   Foo::odin

I've tested this with gcc v3.4.4 and gcc v4.0.2, and it seems to work fine on both. Since I'm not a gcc hacker, my implementation might not be the optimal one, but it works for me. Isn't open source great sometimes?