FIXING LEAKS

The big news this week is that Kyle Huey made chrome-to-content leaks impossible. Kyle wrote about this in some detail. This particular kind of leak can happen in Firefox, but more importantly, it’s responsible for most of the leaks in add-ons that we know about. In other words, it should greatly reduce the problem of leaky add-ons, a problem I previously identified as the #1 MemShrink issue. It’ll take a while to see the exact effects and whether they match expectations. Nonetheless, this is a big deal!

Olli Pettay fixed a leak relating to Geolocation.

The following add-ons had leaks fixed: Collusion, SearchMenu, panchang, HTML5 Extension for Windows Media Player Firefox Plug-in.

Slimmer data structures

I reduced the size of JSScripts (here, here and here). This increased the number of JSScripts that fit in a GC arena from 31 to 42 (on 32-bit platforms) and from 19 to 28 (on 64-bit platforms). This reduced the size of the “scripts” entry in about:memory — which is often multiple MB for the compartments of complex web sites and apps like Gmail — by approximately 30%. (The final two patches in the sequence are being held up by the current tree closure, but will land as soon as that has passed.)

Nathan Froyd reduced the size of mozilla::dom::Link — one of which exists for every <a> or <link> or <area> element shown in a page — by 4 bytes (on 32-bit platforms) and 8 bytes (on 64-bit platforms).

Ehsan Akhgari reduced the size of nsEditor — one of which exists for each text area in a page, and some other places — by 16 bytes on 64-bit platforms.

Quote of the FORTNIGHT

PC Advisor featured an article about browser performance. The article criticized the standard browser benchmarks for (a) not representing everyday browsing and (b) underestimating the effects of memory consumption on browser performance — two things that I agree with.

The article also presented some cross-browser memory consumption results from real-world-ish workloads. The testing was imperfect — for example, it didn’t measure memory consumption after any kind of prolonged usage — but I liked the fact that the author had actually thought about things instead of just mindlessly running the standard benchmarks.

And with my PR hat on, I was happy with the conclusion.

Firefox is the clear winner of the bunch. It was the only browser that did not slow things down and I recommended it for both lower-end mobile devices and high-end desktops.

In general, cross-browser memory consumption comparisons are difficult to do well. My preferred method is to run some set of benchmarks on a machine with a small amount of RAM, as that gives a genuine indication of the performance effect. “Browser A was 50% slower on benchmark X when I halved the available RAM, but browser B was only 10% slower” is much more meaningful than “Browser A used 20% more memory on benchmark X than browser B”. Choosing good benchmarks is still not easy, though.

Bug counts

Here are the current bug counts.

P1: 21 (-1/+0)

P2: 85 (-14/+15)

P3: 104 (-5/+9)

Unprioritized: 1 (-0/+1)

I’m thinking about omitting the bug counts from future MemShrink reports. I don’t feel like they add much, but I’d be interested to hear if people think otherwise.