Over a week ago, I collected the data I said I was going to look at last time. I finally had a chance to look at the data (startup times with and without add-ons for two profiles on the latest version of 3.6), and my hypothesis was not verified. That means it is back to the drawing board for me. The graphs are not at all interesting, so I am not going to post them. At this point, I think the goal is officially at risk. With the profiles we got, I am not even seeing slow startups with cold startup. It is hard to diagnose a problem you cannot reproduce, sadly.
Next week I am going to sync up with limi and get some contact information from the people that sent these profiles to us. We are going to have to do some remote debugging to see why they see such slow startup times.
News on the Past
Paul is feverishly working on a solution to make session restore not kill us on startup. He even has some test builds which you can download and test, but these are experimental. You should make a copy of your profile as a backup when using this test build in case things go boom.
You can go grab it on AMO or wait for Thunderbird to tell you to update. This contains a one-line work around that makes the add-on work after the semi-recent change in the API. You can read all the fun details over in bug 586032.
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:
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!).