So, after months and months and months and months of work (that's almost seven months of work, for those keeping score at home), we are now on PPCBC, the PowerPC-specialized form of BaselineCompiler, and our hardworking methodjit is now released to that great tracing monkey in the sky (though a large part of it lives on in the regular expression library, and some portions are still used by Ion). Was it worth it?
IonMonkey, which we don't yet implement, is a high-latency compiler emitting very optimized code. But its latency comes at a price, particularly on single processors where compilation cannot occur in the background. In fact, Mozilla does not even try to invoke IonMonkey until a particular block of code has run at least 10,000 iterations; it doesn't pay off.
BaselineCompiler (I'll discuss PPCBC in a moment), on the other hand, is a low latency compiler, even lower than TraceMonkey. The browser will attempt to compile code running with as few as 10 iterations (!) in Baseline because there is little penalty to doing so: even though it generates low-quality code, the code that it does generate is over four times faster than the interpreter, and because it generates it so quickly the browser can start executing this code nearly immediately. However, it generates code that is about 60% slower than TraceMonkey, and about 7 times slower than JM+TI.
Fortunately, most pages do not have long-running scripts; they have quick-hit scripts, and most of them are using integer or object-based code. This is where PPCBC shines. Pages become significantly more responsive and because we jump into compiled code with a very short delay, there is much less wait. Many, though by no means most, sites fall into this category. YouTube is a site that could go either way, but eBay does very nicely. Gmail feels about the same, but at least it does not regress.
The definitive solution is to implement IonMonkey fully, of course. When fully operational, then after a period of time running, PPCBC-generated code will have accumulated enough type information to allow IonMonkey to emit very nicely optimized sequences, better than JM+TI would have generated for the same input. The good news is that implementing PPCBC first gets us about 2/3rds of the way to Ion since they use most of the same underlying machinery, and it is a predictably performing compiler which is important for our low end systems. (By the way, do not try to enable Ion in the browser. It will crash. You may need to restart it in safe mode to turn this off, so please don't. If you are using the js shell, be sure to start it with the --no-ion option.)
TenFourFox 24 does have better graphics support and improved DOM performance which helps to offset some of this performance loss. We are also using different widget code required by the Australis upgrade, which is improving some of our chrome drawing speed (more about Australis in a moment). I did attempt a build with jemalloc in it, the higher performance allocator that Firefox preferentially uses and that we did attempt an unsuccessful test build with back for the 22.1 release. We scotched it back then for being unable to deal with a memory leak, and jemalloc makes 24 even worse: overnight it ballooned to almost a gigabyte of memory on my quad G5. In addition, the performance delta between regular and jemalloc is much smaller for 24 due to improvements in the core and it only makes a small difference on a subset of sites. So it's not worth the headache now.
The only outstanding bug of significance so far in 24 is a problem with Personas covering up the "traffic light" buttons on redraw (issue 247). It's cosmetic; they repaint when you hover them, and they work normally, so it's just an ugliness that needs to be polished up. This will be fixed for the final release and does not occur with the regular chrome. YMMV, do report as you find them.
Localizers should consider strings frozen for this release, so language packs for 24 can now be created. I am thinking we will have one more beta (24.0.1) to coincide with 17.0.10, and then 24 will replace everything for 24.0.2; langpacks should be ready to go by then. I'll let Chris Trusch comment on the feasibility of that timeframe. Our long-suffering and greatly valued volunteer translators should look for activity in issue 42.
Looking ahead to the future, I am not likely to land Ion on 24 if we can get at least Fx26 running. The reason is simply because I don't know how our systems will deal with it; it's a heavyweight compiler, and it may be too much to be efficient on a G3. We might even only ship it for 7450 and G5, and let G3 and 7400 use Baseline only, which may perform more smoothly on those significantly older machines. However, because PPCBC works fine, Ion is now officially a "solveable" problem given enough time. Evaluating its responsiveness will thus be a big part of the upcoming new unstable branch releases.
What isn't necessarily a solved issue, though, is Australis, the new interface. Some of this code is already in 24, invisibly, and we use some of it for Personas (so fixing the Personas bug is important not because it's cosmetically wacky, but because it's a useful test of code to be used more heavily in a future browser version). However, it still has lots of performance regressions and bugs and it's not even a part of Nightly Firefox builds, just the UX branch; it is now debatable it even makes Firefox 27. Whenever it lands, we need to get Australis working to advance, since almost all of the browser chrome will depend on it; the odds are good as long as 10.6 support doesn't get dropped given our success thus far, but by no means guaranteed.
Anyway, I am relieved that 24 is not an utter disaster. Let me know what you think. I will start working on 26 beta in the very near future as well to kick off our assault on the next ESR, the far-away ESR 31.