Skip navigation

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!).

6 Comments

    • bastiaan
    • Posted July 24, 2010 at 14:27 (2:27 pm)
    • Permalink

    It seems to me there’s no way to eliminate disk access delays, although they can probably be reduced somewhat.

    I think a better way to solve this problem would be to delay loading the profile tabbing data until the Firefox window, with one empty tab, is available. Then the previous tabs can be loaded in the background while the UI is available to the user.

    • jmdesp
    • Posted July 25, 2010 at 01:46 (1:46 am)
    • Permalink

    Loading time with many tabs should be a *top* priority for Mozilla. That’s a major real life problem. I go with bastiaan’s solution : delay loading of tab, only show the title, load them when the user selects them. People with a problem of large number of tabs actually use them as some kind of alternative to bookmarks.

  1. BarTab!

    It is very simple but VERY affective.

    Quote:
    “So you keep open tabs like libraries keep books… Aren’t you afraid Firefox will consume all your memory? Don’t you fear browser restarts because it takes so long to reload all your tabs?

    Well, you shouldn’t! Because now you can put all the tabs you don’t need on your bar tab, and only pay for the load when you actually want to visit them.”

    >startup time scales linearly with the number of tabs session restore has to restore.

  2. This is one of the most important issues that needs to be mitigated in our next release, so I’m terribly happy you’re on the case. I too love Bar Tab and wonder how we might integrate the best parts of Bar Tab into a release. I realize that is a little orthogonal to what you’re trying to fix but Bar Tab significantly changes startup time. I think we need to fix the underlying issues too of course.

    • pd
    • Posted August 13, 2010 at 23:57 (11:57 pm)
    • Permalink

    Would tabs in separate processes make start up a helluva lot faster? Has there been any movement on this feature that Firefox competitors have had production released for a long time now? Are the Electrolysis (?) people on to it?

  3. Creating processes isn’t exactly cheap, so I don’t think it’s the performance win that everything thinks it is (for additional other options too). Work is under way on this, but it will not make Firefox 4.0.


Comments are closed.