Snappy June 21, 28

Necko team is busy squashing main-thread waits, see bug 765665, bug 766973.

Ehsan Akhgari turned on frame pointers on nightly channel: bug 764216. This means that one can now use the built-in profiler on nightly builds. The main purpose behind the change was to collect more chromehang data(long Firefox UI stalls). Vlad Djeric lowered the chromehang reporting threshold to 5 seconds: bug 763124. We are waiting on metrics to separate out chromehang reporting from telemetry pings: bug 763116.

Nathan Froyd is making heroic progress on teaching our events to queue so they can be prioritized: bug 715376.

Tim Taubert is working to reproduce a tab animation regression in bug 752837. He also taking over making Firefox themes less of a performance pig in bug 650968 .

We had great success with eliciting data on slow startups in Nicholas Chaim’s blog post.  We confirmed that external processes can affect Firefox startup (we had evidence for this) and that we can detect those situations (great work Nicholas!). It will be a hard slog before we can bolt a pretty UI to the extension + integrate system diagnostics into Firefox. In the meantime I recommend that SUMO people start suggesting this extension to diagnose slow Firefox installs. Nicholas is working on a revision of the extension that records slow-IO-caused-startup situations on a server so we prioritize + turn these into detectable fingerprints.

William McCloskey fixed a nasty GC regression which caused GCs to run too often: bug 768282. Andrew McCreight sped up cycle collection when closing tabs: bug 754495. Olli Pettay enabled freeing DOM nodes directly (bypassing cycle-collection) when setting .innerHtml of non-empty DOM elements see bug 730639.


“The Performance of Open Source Applications” book is looking for contributors. Would be cool if someone snuck some Mozilla wisdom in there.

Sorry for skipping the snappy update last week. These posts take a lot more effort than is reasonable and I needed to direct it at my talk last week. You can see my Velocity slides here.

At least one person objected to the strong language used in the presentation (ie “dom local storage sucks”). I chose this language to emphasize the fact this isn’t a feature where one gets to weigh upsides vs downsides because the downsides are so severe. Most of the positive data on this is coming from what I believe to be unrepresentative benchmarks. I have not seen any other data points similar in quality to those reported by our telemetry.

Btw, Jan Varga is close to removing our IndexedDB prompt(bug 758357), opening up IndexedDB as an alternative to DOM Local Storage(which sucks).


  1. Nicholas Nethercote

    “These posts take a lot more effort than is reasonable”. I view my MemShrink reports as having two purposes. First, they keep interested people up-to-date with what’s happening. Second, they serve as a form of PR to counter people who say “Mozilla doesn’t care about memory consumption”.

    I also record notable MemShrink things (bugs fixed, blog posts written, etc) in a text file when they happen. And I have a saved Bugzilla search that tells me all the MemShrink bugs that have been fixed in the past week. These things make it easier.

  2. +1 to Nick’s sentiment. I’m someone who finds these posts very interesting and encouraging. Don’t think that your hard work is wasted; there are definitely people who appreciate it.

  3. Thanks guys. I didn’t mean to suggest that I’m wasting my time; just that I am a slow writer. I regularly get useful feedback that helps me understand relevant problems better and brings up problems I missed.

  4. I find Snappy & Memshrink’s updates incredibly useful tools to convince people that Firefox really isn’t a slow memory hog – especially the people who insist it’s getting worse with time. Maybe at one point that was true, but not for months. Thanks to reading these updates, whenever I get into these discussions I can point out a dozen ways things have improved *in the last month*. If someone’s really stubborn, showing them Areweslimyet, about:memory, Telemetry data & bringing up some Bugzilla reports normally does the job. I’ve convinced a few switchers to at least try Firefox again.

    My point is, don’t feel like these posts are going to waste or they’re pointless! They’re really valuable PR material. 🙂

  5. thanks for this post. i like to read about what’s going on with my fave browser. the thing for me is that Snappy & Memshrink’s work is making things better for me because i use a screen reader and any lag is 10 fold as i am always waiting for the speach to start. the uther thing is that wen ff’s memory use to get out of control and crash it wood take my screen reader with it wich wood leave me scrood as i wood have to reboot! so keep it up pleas both you and nik. thanks