Firefox Startup Performance Weekly Summary

Recent activity:

  • An improvement in startup time on Mac Leopard of around ~16% (aka: Very Large) was found by Joel Reymont and fixed by Masayuki Nakano in bug 517549. Mac users rejoice!
  • The Windows cold startup regression from 3.5 to 3.6 being tracked in bug 517741. Help finding the window for this would be awesome.
  • JAR Performance: Alfred Kayser has a new patch on bug 510844 which should increase throughput of JAR file reading, about ready to land.
  • Ben Hsieh is making progress removing the needless stats of already-fastloaded components and other stat removals in bug 511761.
  • Service caching work is still in progress in bug 516085. Drew’s tests showed no significant win on Tp, but the patch did reduce IO service retrievals by 58%. It might be worth pushing this to the Places branch to get a better idea of the total performance impact of the change.
  • Ryan Flint landed bug 499123, combining a bunch of about: pages into a single component, on 1.9.2 branch for Firefox 3.6.
  • Bookmarks toolbar: I put a patch on bug 504858 that pushes back the population of the toolbar until after the browser window comes up. Checking into the Places branch showed a 1.5% improvement to warm startup on Windows. Just waiting on review.
  • CSS Parsing Time: Zack is working on major CSS parser changes in bug 513149.

Projects in a holding pattern:

  • Preference Files: Taras Glek has been working on combining the different preference files into a single one at build time, in bug 507288. The patch is there, and is just trying to find a way to land cleanly.
  • Cold Startup Testing: Drew and Alice made a bunch of progress on bug 510587, to create a new Ts that measures cold startup. Alice is working on mobile Talos though, so this is sidelined for a bit. The only issue left is reliable Windows measurement, but we’re not going to block on it, can live with Mac and Linux to start off.
  • JARification: David abandoned moving JS modules into a JAR file, since those files are fastloaded. However, since we want things like post-extension-install restarts to be fast, and those cause fastload cache invalidation, we might want to do things like this anyways. I filed a bug for the same treatment for components. These are lower priority, since they’re not the normal startup case. Follow along with all JAR-ification via the tracker bug.
  • Startup Timeline: No updates, still not landed. Add [ft] in the whiteboard of your bug w/ the function names you want timed and David will generate it and update the bug.
  • PGO for Places, mozStorage and SQLite: Still blocking on Rel-Eng fixing bug 486783, which now has patches!
  • Static Analysis: No progress on bug 506128. David needs to file a bug with the final log of named-yet-uncalled functions.
  • Dirty Profile Testing: No progress. Need to list scenarios, file bugs for each, generate Talos config patches and profile data, and then move it into Rel-Eng territory. Also, need to get a separate Tinderbox tree, since it’s going to cause a bazillion new columns.
  • Joel Reymont noted in bug 513076 that there are serious drawbacks to getting our libraries in the dyld shared cache on Mac, so has deprioritized that work.

6 Comments on “Firefox Startup Performance Weekly Summary”

  1. Taras says:

    You missed progress https://bugzilla.mozilla.org/show_bug.cgi?id=412796, apparently it is another 10% cold startup win. Couple that with Ben’s stat()ing bug you mentioned winning 3% and we had a pretty productive week🙂

  2. The “unit tests on nightly builds” went into production on Thursday, it just hasn’t been marked as fixed yet. I’m not sure if it’s running on the Places branch yet, might just be mozilla-central right now.

  3. IagoSRL says:

    Hi!

    Would it be possible to create compiled (or tracert?) javascript files using the Tracert engine?? (with small changes in the engine; in a similar way to python)

    Could this help to improve performance by load ‘tracert’ javascript files, instead the plain javascript files? Css files would be converted into javascript-css and then compiled. And a similar for xml, xsl -serializating a DOM tree?- or xul -converting elements into javascript functions calls?-?? And all together in a ‘tracert’ file instead a jar file (and one per extension)??

    Maybe this be a crazy/ignorant idea but, Do you think would be possible, and positive in performance terms?
    ————

    Good work!

    • Yes something like this is being investigated. Our fastload system does basically what you describe, and we’re investigating shipping that cache prefilled. It’d reduce i/o at startup as well as js compile time.

  4. “Dirty Profile Testing: No progress.”

    As much as it’s cool to see all the other stuff happening, I’m afraid it all seems pretty much irrelevant for me. On my home computer, and several computers in the office, the cold start time is 30-40 seconds. Trying out latest trunk, I see no improvement, but that’s quite possibly because all the improvements are lost in the noise.

    Startup with a clean profile is around 8 seconds. Shaving a second or two off that is nice, but shaving a second or two off 40 seconds doesn’t help much.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s