Well, let's just wave our hands around a bit with 31.0b3 for you

Today in the USA, we celebrate July 4th where America freed itself from the little-endian tyranny of King Tim by throwing Mac Pros into the harbour. Or something like that, I was always daydreaming about Alyssa Milano in civics class. Anyway, Beta 3 is now available (downloads, release notes) corresponding to the Firefox 31 beta 6 code drop. I am not able to distinguish much performance difference from 29 now, and the initial beachball with Adblock is gone on the quad G5 and lasts only a few seconds on the iBook and iMac G4 systems. On battery in Reduced mode, I consider my iBook G4/1.33's performance acceptable -- I can get into Gmail and my office mail much more quickly, and scrolling is significantly less sluggish. This also fixes the problem with spurious extra Window menu entries. Make sure you update your Adblock Edge and Plus; there were some recent updates for ABE, at least.

There were two problems with JavaScript, and I appreciate Chris Trusch for giving me reliable figures that I could replicate (performance issues cannot be fixed without them). For this purpose I compared performance in debug builds, which is not something I usually do for obvious reasons and is what led to me finding the second problem. Indeed SunSpider and microbenchmarks were performing worse in 31 and it turned out to be another side effect of the added Ion optimization analysis I had to work around once already. I added another check to not run it except in the situations that 29 runs it, and while the analysis is more heavyweight than 29's, the added improvements to inline caches in 31 generally even the impact. I think I can port this change forward; it's not very complex. Interestingly, V8 was at most fractionally perturbed by this, at least on the quad, so we're going to have to watch both benchmarks again in the future.

However, when I built the optimized version, it was still the same speed as beta 2 despite the debug build now being substantially faster. That didn't make any sense at all. Why would a debug build now beat the optimized build by almost a factor of two? It's not only bigger, it's deliberately more inefficient!

After about a week comparing source code, it became obvious that indeed there was nothing in Mozilla's debug code that was doing an operation with side effects or something getting cached that wasn't in the opt build. To prove that, I turned Mozilla's -DDEBUG on for the G5 opt build and the numbers indeed sank further. Incredibly, Shark would run the JS shell at least (even if it won't run the browser, so now I'm reexamining my theory about pilotfish -- perhaps it's just objecting to the size of XUL, which would not be surprising), and comparing the performance traces in Shark showed that the G5 opt build was slow across the board even in things that had no debug code at all, like C++ object constructors. WTF?

The other difference in a debug build is the compiler settings. So, over the second week, I did like we used to do to find the bad extension and ran and re-ran builds with different permutations of compiler and build settings to find the setting in the debugging configuration file that made the difference. And the winner was, incredibly, --enable-debug-symbols=-gdwarf-2 -- adding that to all the optimization configs greatly improved performance. For JavaScript, and now the entire browser, the opt build is once again substantially faster than the debug build just as you would expect. (One other note is that the G5-specific branch stanzas we relied on for 11-29 look like they are not working well in PPCBC, so the G5 build now uses the same shortened branch stanzas Ben innovated for JaegerMonkey on G3 and G4. This further improves V8 by about 8%.)

I don't have a good explanation for why DWARF-2 symbols weren't needed in 29 but are needed now; all I can think of is that somehow we crossed some internal maximum and we need the more efficient modern representation, even though the opt build does strip out most of the symbol table. This may have a consequence for debugging and crash reports, but I don't think we can go back to the old STABS symbols for 31. We'll just have to deal with the problems as they come up.

Your remaining homework:

• I'm toying with bumping the GC timeslice back to 100ms as it was in 29 (it remains at 30ms right now, same as 24). You can try this by setting javascript.options.mem.gc_incremental_slice_ms to 100 and restarting the browser. This should not make much immediate difference; this is for later on when there are more compartments for the garbage collector to search. I just want to make sure that it doesn't slow the browser initially.

• Now that we have substantially changed the browser foundation, we should reexamine some earlier performance conclusions. If you are on a multi-core Power Mac, such as a dual G4/G5 or the quad, try turning OMTC back on and restarting the browser. Does it help? Does it help on a uniprocessor Mac? It's hard for me to judge on my test systems. To try this, toggle layers.offmainthreadcomposition.enabled to true and restart the browser. The G5 seems a bit better, but it's a wash on the iMac, and the iBook is still questionably worse.

• The most important question: release 31 on time on July 22, or wait for 31.1? It's important to us to prove to the Mozilla community we're still a viable and well-maintained port, and I'd like to release on time to make that clear. However, if you have a good reason to wait, I'm willing to consider it; either way, though, we will release no later than 31.1. We need to stay current and ESR24 is going away.

I have not come to a firm decision about dropping source parity, though some code changes in 33 are making me unhappy (they're not portkillers, but they're a lot of work and will invalidate substantial portions of our changesets). I might jump straight to 33 from 31 to deal with those and the irregexp migration at the same time. If that goes awry, that would make my decision for me.

One outstanding bug is a printing crash on Tiger Server only. I have never supported the Server versions of 10.4/10.5, mostly because I have no way to test them and I don't have a need to run OS X Server personally. However, if you're using it, please look at issue 279. While I will not hold the release to fix this and I don't have the ability right now to fix it myself, if you do, I will accept your patch as long as it doesn't regress the regular OS X client versions.

In July we will have our annual state of the Power Mac userbase, and I also have some fun future blog posts in the hopper on my expensive but incredibly fun Amiga 4000T (with Picasso IV, 68060 CPU card and Hydra NIC), and my old Wallstreet G3 now dualbooting Rhapsody 5.6 (Mac OS X Server 1.2) and OS 9.2.2. Plus, I picked up a Cube G4 when I was in Berkeley last week that's waiting for a power supply. The shell is in excellent shape with no major nicks or scuffs and I think it'll be a great test system for playing around with MorphOS in my copious spare time. If you're in the Bay Area and looking to pick up some more Power Macs, they've got plenty at M.A.C. on University and Shattuck and they're willing to deal. Check it out.