Snappy #46: December Progress

Taras is on vacation this month, so I’m filling in with a Snappy progress update. Taras also has a mini-update on his new blog: Snappy #45: The View From Home.

We are working hard on improving Firefox start up and shut down and much of the work is being done with the help of the new startup & shutdown profiling modes in Benoit Girard’s profiler. In general, we are finding that GC and CC make up a significant fraction of shutdown time. The ongoing exit(0) project is going to be the biggest win for shutdowns, but startup times will likely require many smaller improvements. We also seem to be up against against a gradual and relentless increase in startup times with each release (bug 818257). This may be a consequence of increased code size and our decision to load all of xul.dll on startup.

Over the past month, several patches have landed aiming to improve startup times, but we can’t quantify the user benefits until the server-side bucketing of Telemetry measurements becomes more fine-grained (bug 778809). David Teller made improvements to startup by moving the reading of the session file (bug 532150) and the search bar metadata (bug 760036) off the main thread. Aaron Klotz landed a patch (bug 810101) to read the SafeBrowsing .sbstore and .cache files with the “read-ahead” flag. These files total several megabytes and Aaron’s local testing showed a 50ms reduction in file read times. He also discovered that the .sbstore files get read shortly after startup when we first try to open an HTTP channel.

On the shutdown side, Benoit Girard landed code to skip the destruction of cross-compartment wrappers during exit (bug 818296). He also landed another change (bug 816656) to prevent flushing of the startup cache to disk while shutting down a brief session. Olli Pettay’s bug 818739 stopped the Cycle Collector from being run on shutdown in non-debug builds.

There were also a couple of general responsiveness patches deserving mention: Vladimir Vukicevic landed bug 731974 which promises to considerably improve the smoothness of UI animations, Rafael Espindola moved the reading of a Telemetry data file off the main thread (bug 815709) and Drew Willcoxon refactored the content pref service to use async storage (bug 699859).

James Abbatiello, an external contributor, wrote an extension to track tab switch times to help us identify pages we don’t handle well. The extension adds the last switch time (in milliseconds) to tab titles and shows a full list in an “about:tabswitch” page.  If you’re interested in helping us identify problematic pages, install the Addon Builder Helper and the current draft of James’s extension and consider filing bugs for any URLs which consistently require more than 50ms.

Lastly, I moved LocalStorage writes off the main thread, which ought to provide a relief from a major source of UI unresponsiveness.  LocalStorage has been a top source of slow main-thread SQL for a long time: http://bit.ly/WEOwPC (sort “Latest Changes” section by “Total Sum” column). Honza Bambas is working on a full re-write of LocalStorage (bug 600307) which also adds pre-fetching.

8 Responses to Snappy #46: December Progress

  1. Lots of Off Main Thread fix which I just collectively called OMTx.
    Would Gnerational GC help with start up? And any news on SuperSnappy?

    The other thing that recently got my attention was increased code size as you have mentioned. Will that be looked into in the foreseeable future?

    • I don’t think GC is a major source of startup slowness, but if we ever found that to be the case, we could look into postponing the first GC.

      I’ll be looking into the slower startups this week and the next. For a first cut, I plan to compare startup profiles of recent and old builds. This might help identify any major regressions. If we find that code size is the major culprit, we’ll have to look into other strategies for loading xul.dll and using tools like syzygy.

  2. “This may be a consequence of … our decision to load all of xul.dll on startup.”

    Perhaps this is a silly question, but would it make any sense to split up xul.dll? Perhaps see what is actually used initially & divide accordingly.

    • Yes, it might make sense to relegate self-contained, infrequently-used features to a separate binary, but I need to investigate if anything matches the criteria.

  3. Please keep us uptodate about the startup improvements. I think the current startup time plays a significant role in the “Chrome is faster than Firefox” debate.

    • I think you’re right, and I’ve been told of a market analysis that showed that startup time is the #1 performance feature for users.

      • Yes! Cold startup especially should be a major focus area. Normal users close the browser a lot more often than developers do, and their computers are slower, so startup improvements really matter.

        Please use every trick you can think of to make startup at least *look* faster. On cold startup, Chrome draws the window much quicker than Firefox does, and that’s a big deal. I think Chrome just shows a window as early as possible and pretends it’s already loading the home page, but I don’t care, at least I can see it’s doing something.

        I’m aware that it’s a *lot* more complicated than that, but users just want “a fast browser”, and perceived startup speed is a big part of that.

        Thanks for your hard work!