Open Bug 506841 Opened 10 years ago Updated 7 years ago
Chrome Registry::Check For New Chrome runs on every app launch
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.)
10 years ago
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.
10 years ago
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
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: --- → ?
(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?
Seems like we would ship Firefox 4 without this just fine.
blocking2.0: ? → -
You need to log in before you can comment on or make changes to this bug.