There’s been a flurry of activity lately on making Firefox build faster. One thing that’s not talked about much is tailoring what features how build or how you build can make things go faster. Below are a couple configure options that may make your life better, depending on what platform you develop for and what your focus is. None of these are going to help as much as glandium’s xulrunner SDK development trickery, but for those who can’t do that, for whatever reason, these may be helpful. Add them to your mozconfig with ac_add_option or your manual configure invocation if you are oldschool.

--disable-debug-symbols : This option isn’t appropriate if you plan on doing any C/C++ debugging. Really. But if you work more-or-less exclusively in JavaScript (or Java, for Android), this option can make your builds go much faster by making your object files smaller and link times faster. My local Android builds shave 30 minutes of total runtime (!) by enabling this. The actual win is somewhere on the order of 3 minutes due to the wonders of parallel make. Still, 15% improvements are nothing to sneeze at.

: This option isn’t appropriate if you plan on doing any C/C++ debugging. Really. But if you work more-or-less exclusively in JavaScript (or Java, for Android), this option can make your builds go much faster by making your object files smaller and link times faster. My local Android builds shave 30 minutes of total runtime (!) by enabling this. The actual win is somewhere on the order of 3 minutes due to the wonders of parallel make. Still, 15% improvements are nothing to sneeze at. --disable-crashreporter : This configure option builds less code, which is always a good thing. Needing the crashreporter would be pretty unusual for local development, so this is probably pretty safe.

: This configure option builds less code, which is always a good thing. Needing the crashreporter would be pretty unusual for local development, so this is probably pretty safe. --disable-webrtc : Again, ths option is for not building a (somewhat larger) swath of code. May not be appropriate if you’re doing Web Audio or trying to measure startup improvements.

: Again, ths option is for not building a (somewhat larger) swath of code. May not be appropriate if you’re doing Web Audio or trying to measure startup improvements. --disable-icf : This option is only useful if you’re building on Linux and you know you’re using the gold linker. This option turns off merging of identical functions, which makes the linker run slightly faster. (May also work on Windows with opt builds, not sure.)

For development on Linux with GCC specifically, there are a few compiler options that may make your life better also:

-fno-var-tracking : This option makes the debug information for C/C++ slightly less accurate. Variable tracking is a relatively new thing (GCC 4.6+) and tends to suck up quite a bit of compile time. If you were debugging happily with GCC 4.5 and earlier, you may not notice any problems with turning variable tracking off.

: This option makes the debug information for C/C++ slightly less accurate. Variable tracking is a relatively new thing (GCC 4.6+) and tends to suck up quite a bit of compile time. If you were debugging happily with GCC 4.5 and earlier, you may not notice any problems with turning variable tracking off. -gsplit-dwarf : What this does is it separates debug information into a completely different file from the actual compiled code. This change, in turn, makes the object files smaller, primarily for the benefit of the linker. You can read more about the motivation for splitting debug information into separate files on the GCC Wiki. There’s also a bug about adding this by default to local developer builds. (Recent SVN builds of clang also support this option, I think.)

Finally, if you want to dive really deep, you can play around with the options passed to the gold linker on Linux. (And if you do, please post some numbers to that bug; we’d love to get more data on how those options work for people!)