Extensions & Startup

Dietrich blogged a “wake up and smell the startup” executive overview of startup issues caused by our extension practices. This post is a “numbers” followup. For this experiment I installed a brand-spankin-new copy of Linux Firefox 3.6. Firefox is installed on a 7200 hard drive, the rest of my system lives on an SSD. The CPU is core2duo, keep in mind these numbers will be significantly worse for people running on netbooks and other common hardware. The numbers vary +/- 150ms, but the general picture is pretty clear.

Results

Startup Time
Firefox 3.6 with no extensions: 2240ms
+Adblock Plus (no subscriptions) 2538ms
+Video Download Helper 2727ms
+Personas 3220ms
+Greasemonkey 3300ms
+EasyList subscription for adblock 4044ms

I just doubled cold startup time for Firefox by merely adding 4 extensions. It takes weeks or even months of developer time to shave off every 100ms off Firefox startup, but mere seconds to undo any of those gains by installing extensions. These are just the top-4 extensions in the list (presumably they are higher quality too), I’m sure there are lots of other extensions with more drastic performance hits.

Dietrich’s post details some of the remedies that should reduce the startup cost of extensions. For the inquisitive minds: I used SystemTap to produce a report of files read by Firefox on startup ordered by their startup cost.

Update:
Dietrich asked me to summarize warm startup too:

  • Without extensions: 550ms
  • With above Extensions: 1800ms

Note that this is a developer blog, so by “remedies” I meant “things developers can do to”. There is little normal users can do short of complaining to the extension authors.

This post isn’t meant to shame specific extension authors into speeding up their extensions. The aim is to show that a measurable percentage of startup is due to extensions and that we need to:

  1. Educate extension developers about it
  2. Provide better tools to measure slowdowns caused by extensions
  3. Make sure that the Firefox side of extension handling is sufficiently efficient

21 comments

  1. “Dietrich’s post (linked above) details some…”

    Hm, it seems you forgot to actually link to this post. Or maybe I am just unable to find it. Can you give me a hint?

    thanks,
    xeen

  2. Hi Taras,

    “Dietrich’s post details some of the remedies that should reduce the startup cost of extensions”

    I’ve read Dietrich’s post but it does not detail ANY of the remedies that should reduce the startup cost of extensions, at least not for users!

    It gives some suggestions to the extensions developers about the remedies that should reduce the startup cost of extensions and it says two things about what the users should be able to do, but as a future project for Firefox, not really suggestions for the users related to how to reduce the startup cost of extensions.

    Should I have misunderstood, could you please detail me some of those remedies?

    Many thanks,
    Best regards,
    Gabriela

  3. Can we try Norton Internet Security Toolbar, Yahoo Toolbar, The Browser Highlighter? (Those are things we commonly see when users complain about startup time on support.)

  4. Could you try to strip localizations from the addons? I’d be curious if we’re actually spending significant time when the chrome reg actually needs to choose the right locale.

  5. Russell Milliner

    Why not have the option of a splash box at start-up that has a status when each extension is being loaded. It would barely show up on a fresh install. This would give the average user the feedback of why their browser is taking so long to load, and would make bad extensions even more obvious.

  6. I don’t think that vilifying developers is a good idea by saying “make bad extensions even more obvious”.

    Just because an add-on may affect startup time, doesn’t make it a bad one and while I (a long time Add-ons user) have known that startup time and overall performance is affected by the amount and types of add-ons that are installed, I know that many to most mainstream users don’t know that, and also, I don’t recall there ever being a significant discussion out in the open about the issue of add-ons affecting startup time (and/or performance overall). Not on mozillaZine, the AMO Blog, or any credible and highly visible media outlet.
    I’ll bet that a lot of add-on developers have never even thought about it.

    A brand new Firefox profile launches in mere seconds for me (Win Vista), while my primary one takes maybe, a minute and that’s with 65 enabled add-ons (I typically run 90+, still about a minute) including (of course) Personas and Adblock Plus with EasyList and EasyPrivacy.

    I’ve never understood the whole startup complaint anyway.
    It’s pretty rare nowadays for someone to not launch their browser and leave it open when they power up their computer. And it’s common sense that anything that you add something to is going to get heavier and slow down.
    Chrome users will soon discover this.

    In any event, I like Asa’s suggestion (http://weblogs.mozillazine.org/asa/archives/2010/03/startup_penalty_repo.html) a lot. A wicked lot.

    Mozilla has to be real careful about how they educate people on the matter of how add-ons affect startup time and performance since add-ons are the primary reason for retaining a lot of users who are on the edge of jumping over to Chrome, and they are what really sets Firefox apart from other browsers, but, people do need to be educated so that they stop blaming Firefox itself for startup and performance issues.
    Out of the box, Firefox is blazing.

    Again, it has to be done carefully because you don’t want to see criticism and attacks like, “Firefox Add-ons are awesome! (if you don’t mind them slowing you and your computer down).

  7. Would it be possible to put this in an extension? Or to make a program that first starts the benchmark and then starts Firefox? It would give a lot of people something to play with and maybe they find solutions to common slowdowns.

  8. Before any development/benchmarking tool is released to mainstream users, it should first be made available for extension devs, then nightly testers and finally to mainstream users. The extension authors should be given atleast 1-2 months to optimize their addons, before the benchmark numbers are publicly released.

    Its quite possible for news sites and blogs to have a field day criticizing and comparing addons, spilling bad blood.

    So whatever the decision is, it should be taken delicately, not antagonizing addon authors who are a very important part of the community

  9. Unfortunately, I cannot see why Adblock Plus without EasyList would result in a 300ms startup penalty. Sure, processing EasyList takes time (for me with Windows 7/Minefield: 210ms to parse the data, 70ms to build up the lookup table which allows efficient processing, 150ms to register the global stylesheet built up from element hiding rules). This isn’t great of course yet I don’t see any more ways to optimize this. But other than that there isn’t much. All the other overhead that I can measure (XPCOM component initialization and overlay initialization in browser window) seems to take 100ms in total. Which probably means that most of the penalty is coming from applying two overlays to the browser window (something that I cannot measure). At least reading various extension files doesn’t seem to be the problem according to your measurements.

  10. Will adopting a Google Chrome-like extension system (i.e. Jetpack) help with the startup time? Since Chrome allows to start/stop extensions during runtime without the need to restart the browser it has the luxury to defer initialization of the extensions until the chrome is visible and usable which probably really helps with the impression of a quick startup.

  11. Erunno, initializing extensions when Firefox is already running is planned for a future Firefox version (3.7?) and will be available to all extensions, not only Jetpack. However, while this is very useful when installing extensions, it won’t help Adblock Plus reduce startup delay for example – it needs to initialize before session restore kicks in, people won’t like having ads in the restored webpages.

  12. Like Ken already mentioned, startup is a problem, but you don’t do it that often, especially compared to page loads and requests (like XHR) which are more problem for me. Also, writing idle tabs as cache onto disk and load them as they get focus would also speed thinks up. Last but not least, Garbage Collector bugs should be triaged better. I have on open which I could reproduce with a new profile and causes Firefox to take a long time to shutdown (with 3.5 up to 20 minutes), and noone cares about it (have similar reports from other users).

  13. Don’t know what happened, the second “Erunno” above is me :-(

  14. > Note that this is a developer blog, so by “remedies” > I meant “things developers can do to”. There is
    > little normal users can do short of complaining to
    > the extension authors.

    But normal users are *not* complaining to extension authors, so we don’t understand why we need to do *anything* at all. This is just a made up problem.

  15. Hey Taras,

    What’s the penalty paid for JetPack extensions? Anecdotal evidence supporting your claims might come from doing a similar test with Google Chrome installed with some of its more popular extensions. At this moment, Firefox is receiving flak for being perceivably slower than Chrome. The numbers from a similar Chrome test will dispel any misconceptions.

    Manoj

  16. Do disabled extensions affect startup time?

    What about having a large number of spelling dictionaries?

  17. >> Do disabled extensions affect startup time?

    I’d also like to know this.

  18. Whoa!! I’ve about 30 extensions running. Ha ha.. I’ll live with it. There’s no such thing as free lunch.

    Suggestion: Could you get the add on developers to provide the startup delay details in the install page?

  19. I’d think that disabled extensions do at least in some extent impact startup time, as I for example do get update offers for firebug on 3.7 nightlies, where I disabled it. So some of it is still in the system.

  20. Do it, make it available as an extension. Hiding it from the user is sort of an elitist attitude.

  21. Speaking as one of the maintainers of Greasemonkey, that number is just a lower bound for startup time — if you install some script(s) that store large quantities (say, tens of kilobytes) of data with GM_setValue, those times will skyrocket, as Mozilla’s prefs.js read-in time at browser startup and write-out times at browser quit time don’t scale diligently.

    I would npt be surprised if that time counts for a sizable share of times for some of the extensions marked as culprits here.