506841 - nsChromeRegistry::CheckForNewChrome runs on every app launch

Status: NEW

(Toolkit :: Startup and Profile System, defect, P2)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

nsChromeRegistry::CheckForNewChrome at http://hg.mozilla.org/mozilla-central/file/935b2a87e42f/chrome/src/nsChromeRegistry.cpp#l557 is run unconditionally every time the Chrome Registry service is initialized.  This involves trawling through the chrome dir and reading each .manifest file.

Also, this function checks for app-chrome.manifest, which I'm pretty sure we removed/obsoleted support for.

We should only need to do this if we just upgraded the app, or installed/uninstalled a plugin.  Otherwise we should just have a cache file for this; in an ideal world, a single file that we mmap and have offsets into or something.

(This is 10-15ms of warm start and aroud 190ms on OSX, though that's made worse by the FSRef stuff that's bug 506812.)

Comment 1

[Axel Hecht]

I would think that it'd be safe to throw all .manifest files but en-US.manifest (for l10n repackaging) into a single .manifest file. In case of Firefox, that'd get us from 7 down to 2.

Adding en-US.manifest would make l10n repackaging significantly harder.

Would that be worth spinning off a separate bug? Might be worth testing that upfront.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

That would help some, but we'd still have to iterate over every file in that directory.  The goal would be to just go straight to a file with a well-known name in the profile dir.

Comment 3

[Benjamin Smedberg]

We could avoid iterating using this method:

* Load chrome/chrome.manifest as the only well-known manifest filename.
* Introduce a new manifest instruction for importing other manifests

We avoid directory enumeration and we keep the localized and nonlocalized manifests separate. This will require a little bit of l10n repackaging (because chrome.manifest will change per-locale).

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

The additional packaging cost this late in the game feels like it might be too risky; do we have a sense of the perf gains available here?

Comment 5

[(dormant account)]

(In reply to comment #4)
> The additional packaging cost this late in the game feels like it might be too
> risky; do we have a sense of the perf gains available here?

Upwards of 200ms on mobile. Somewhere > 30ms on desktop. I think for now we can just fastload this.

Comment 6

[Nochum Sossonko [:Natch]]

This will make it difficult to test extensions on the fly, can this at least be preffed?

Comment 7

[Dave Townsend [:mossop]]

Seems like we would ship Firefox 4 without this just fine.