I’ve joked before that I hoped to never work on anything in Firefox that requires me to build the browser regularly.\u00a0 That probably sounds weird unless you are a member of the JavaScript team, because it’s possible to do close to 100% of SpiderMonkey development just building the JS shell.<\/p>\n
Working on the JS shell is great.\u00a0 On my 2.5 year old Linux box it takes maybe 1 minute to build from scratch, rebuilds are almost instantaneous, the regression tests take a few minutes, shell start-up is instantaneous, you rarely have to do try server runs, tools like GDB and Valgrind are easy to run, and landing patches on the TraceMonkey repo is low-stress because breakage doesn’t affect too many people.<\/p>\n
In comparison, working on the browser sucks.\u00a0 Builds from scratch take 25 minutes, zero-change rebuilds take 1.5 minutes, single-change rebuilds take 3 or 4 minutes, the linking stage grinds my machine to a halt, cold starts take up to 20 seconds or more (warm starts are much<\/em> better), the test suites are gargantuan, every change requires a try server run, tools like GDB and Valgrind require jumping though hoops ( Thanks to my recent about:memory work, I’ve had to experience this pain first-hand.\u00a0 It’s awful.\u00a0 Debugging experiments that would take 20 seconds in the shell take 5 minutes in the browser. I avoid ‘hg up’ as much as possible due to the slow rebuilds it usually entails.\u00a0 How do all you non-JS people deal with it?\u00a0 Maybe you just get used to it… but I figure there have to be some tips and tricks I’m not aware of.<\/p>\n--disable-jemalloc<\/code>, anyone?), and landing patches on mozilla-central is stressful.<\/p>\n