A man with a mission...

Startup Time in the Wild

Over the weekend I spent some serious time with my computer running a bunch of tests with standalone talos in 11 different situations. First, a disclaimer: these tests were only designed to give some insight on the areas we should focus on for the goal. Each of these tests was reproduced at least once before I moved onto the next one in order to make sure the numbers were stable.

The Tests

  • Clean profile. This is just the standard profile that we normally run Ts with on tinderbox. This is basically used a baseline for best possible performance.
  • Dirty profile. This is actually my daily profile, with eight tabs that will open through session restore during startup. Because of how talos works, these tabs don’t all have to load for the number to be generated. Even so, you’ll notice a substantial slowdown. Sadly, I fear I modified the profile I was using in a bad way because I can no longer reproduce the numbers I got (but the numbers recorded were reproduced four times before I moved on to the rest of the tests initially).
  • Bookmarks toolbar disabled. This is a variation on the dirty profile test that just disables the bookmarks toolbar.
  • No places. This is a variation on the dirty profile test that removes places files from the profile.
  • No sessionstore.js. This is a variation on the dirty profile test that removes sessionstore.js from the profile. This has the side effect of also not making the eight tabs load at startup.
  • No urlclassifier. This is a variation on the dirty profile test that removes the urlclassifier related files from the profile.
  • No cookies.sqlite. This is a variation on the dirty profile test that removes cookies.sqlite from the profile.
  • No extensions. This is a variation on the dirty profile test that removes all add-on manager bits in the profile.
  • No formhistory.sqlite. This is a variation on the dirty profile test that removes formhistory.sqlite from the profile.
  • No downloads.sqlite. This is a variation on the dirty profile test that removes downloads.sqlite from the profile.
  • No content-prefs.sqlite. This is a variation on the ditry profile test that removes content-prefs.sqlite from the profile.

Results

I’m going to let some graphs do the talking here. The first shows the raw test run data (which isn’t terribly interesting). The second compares the reported startup time for each test. You will probably want to click to zoom in.

Data of the startup time runs


Startup time of the various tests

Conclusions

It looks like the best wins that we can get are related to fixing session restore to not scale linearly with the number of tabs it is restoring, and reduce the startup time costs of loading places files and cookies.sqlite. It should be noted that this test was not measuring the load time for each tab, so something like BarTab would not help in this case. The other good news is that we already have work underway to make cookies.sqlite load time not hurt us so much during startup.

July 26, 2010 | Filed Under Mozilla | 14 Comments 

Perilous Performance Proportions

Recently, I started working on one of our Q3 goals to reduce “dirty” profile startup time to be only 20% of normal startup time. It is a pretty big and scary problem, and is probably the hardest problem I have ever worked on for the Mozilla project (I have had some doozies in the past too…). So far I have only spent time trying to get consistent results of startup time with a dirty profile (of the Firefox kind) so I can then compare profiles (of the program profile kind) to a clean profile (of the Firefox kind). For now, I am just using a copy of my own profile to get some data (no, you cannot have a copy of it).

Unfortunately, I immediately hit a bit of a speed bump. I think a picture best explains this:

chart of dirty startup

This is a chart of the 20 runs talos does when measuring startup time. As you can see, the dirty profile kept on increasing each and every run. After about a day of investigating this, the cause is finally known: tabs. Turns out, talos tries to quit the browser before calling window.close(), which results in the tabs not closing. As a result, at the end of the 20 cycles, we were loading 19 more tabs than the first cycle. I filed a bug about this behavior against talos. It does not matter now, but if we ever decide to change the default preference in Firefox to load your windows and tabs from last time this will come back to bite us.

I did learn something useful out of all of this though: startup time scales linearly with the number of tabs session restore has to restore. I confirmed this by running talos with 200 cycles instead of the normal 20, and it was clearly a linear increase. We should probably figure out a way to mitigate that, but I have not filed a bug on it (yet!).

July 24, 2010 | Filed Under Mozilla | 6 Comments 

sdwilsh Status Update: 2010-07-24

Done:

Next:

  • Get a plan of attack together for "dirty" profile startup goal.
  • Tackle some of the 15 reviews in my review queue (blockers first!)
  • Look into fixing another blocker (I have no more b3 blockers, just beta N ones.)

July 24, 2010 | Filed Under Mozilla | Leave a Comment 

Better SQLite Memory Reporting Coming to a Nightly Near You

I just landed bug 575667 into mozilla-central which adds more detailed reporting about the memory used by SQLite. Some people have been complaining to me that SQLite is using an awful lot of memory lately. My hunch was that most of this was the page cache (so you don’t have to hit the disk for every read), but with the next nightly those people can see for themselves. Now, instead of just indicating how much memory is being used, about:memory states how much is being used by the page cache and how much other memory is being used by SQLite. We are also planning to split this up more, but are waiting for the SQLite team to provide some APIs first.

July 22, 2010 | Filed Under Mozilla | Comments Off 

sdwilsh Status Update: 2010-07-19

Done:

Been a long while since I updated (three months!)

  • Helped get IndexedDB landed
  • So many code reviews...
  • Summit
  • Vacation!

Next:

July 19, 2010 | Filed Under Mozilla | Comments Off