Open Bug 506841 Opened 15 years ago Updated 2 years ago

nsChromeRegistry::CheckForNewChrome runs on every app launch


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




Tracking Status
blocking2.0 --- -


(Reporter: vlad, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [ts])

nsChromeRegistry::CheckForNewChrome at 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.)
Flags: blocking1.9.2?
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.
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.
OS: Mac OS X → All
Hardware: x86 → All
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).
Component: General → Startup and Profile System
Product: Core → Toolkit
QA Contact: general → startup
Blocks: 511761
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?
blocking2.0: --- → ?
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Flags: blocking1.9.2-
(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.
This will make it difficult to test extensions on the fly, can this at least be preffed?
Assignee: nobody → bhsieh
Priority: -- → P2
Blocks: 447581
Seems like we would ship Firefox 4 without this just fine.
blocking2.0: ? → -
Assignee: bhsieh → nobody
Flags: wanted1.9.2?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.