(In reply to Andrew Swan [:aswan] from comment #0)
The function XPIProvider.checkForChanges() does a lot of work whenever we start in a new profile. It also does a bunch of work when the browser is first started after an upgrade, but that's not the focus of this bug. When starting in a new profile, most of this work is synchronously reading, parsing, validating, etc. system addons (https://searchfox.org/mozilla-central/rev/75294521381b331f821aad3d6b60636844080ee2/toolkit/mozapps/extensions/internal/XPIDatabase.jsm#2408)
I did some very crude and unscientific measurements and it looks like on an old-ish mac laptop, all of checkForChanges() takes a few hundred milliseconds. I would expect it to be quite a bit more on a machine without an SSD, so I think there's at least a potential for some significant improvement here.
Nice! Thanks for finding that, I wish this sort of thing showed up on Talos.
I have two ideas:
- Validating system addons is something we can easily do once in automation rather than over and over in the field. This is a little hand-wavy but we could pre-compute the information that's stored in addonsStartup and extensions.json so that those can be created in a new profile more cheaply.
I think it'd be pretty easy to do this at build time, we could for instance store a file inside the omni jar and addons manager could refer to it only when creating new profiles.
- Since system addons authors already can't rely on addon code running early in startup, and since we're generally moving away from system addons, we could defer the initial installation of system addons until later in startup (ie at least after we've painted the first browser window).
I am fine with this in principle, but I worry that it'll cause problems with system add-ons that we're currently shipping built-in, taking a quick look I see:
Would that be affected? I don't think this is the sort of thing we're encouraging moving forward (browser code expecting add-on code to be registered), so fixing the add-on in question / moving this into tree / etc is fine, bit more work than #1 I'd guess.
This has the potential to be a little jarring if system addons that create UI elements are slow to install and their buttons suddenly appear some time after it appears that the browser has already started. I haven't really thought it out but perhaps we could piggyback on the existing webextension startupcache machinery to pre-populate UI elements from system addons to avoid that problem.
I'm wondering if we even need to solve this problem, given that none of the current system add-ons appear in the default UI (Screenshots is hidden in the pageAction menu), I don't know of any plans to build such a thing.
This is obviously still pretty conceptual, looking for feedback at this point. rhelmer, any thoughts about option 2 in particular? (feedback from anybody on either point or on other options I didn't think of is of course welcome as well)
Do you have any thoughts on how big of an improvement you expect these to be? Neither one strikes me as super difficult, but I'd expect to have to potentially deal with more fallout from existing system add-ons with #2.