Chrome Registration needs to happen quicker. It is a bottleneck on startup. It is a thread that seems to block nsDocShell::LoadURI. We are in Chrome Registration for about 2 seconds. --pete
Doesn't chrome registration only happen the first time you startup (i.e., ``install time'')? If that's the case, I think we've got much bigger fish to fry and this should be WONTFIX'd. Re-assigning to XPToolkit.
Assignee: waterson → trudelle
Component: RDF → XP Toolkit/Widgets
QA Contact: tever → jrgm
I think a good solution would be to register everything as a final step at install time. A cheat but a nice one. ;-) --pete
Chris, as long as the bigger fish are performance related thats cool. I'm sick of people showing me how IE and konqueror kick the shit out of mozilla in speed. I'm actually getting sick of it myself. Chrome registration takes about 10 seconds on initial startup not 2. I made a mistake. This is on a dual 500 intel box. So this is a valid bug. --pete
> Chrome registration takes about 10 seconds on initial startup not 2. I made > a mistake. This is on a dual 500 intel box. So this is a valid bug. *Every* startup? Or just the *first* startup, ever, for a new install?
First startup. This is not part of install AFAIK. Chrome registration happens on your first and most important launch of mozilla. It also happens when a new package is added. If chrome registration was part of install, it can mask this perf hit. All the baggage at startup needs to be cleverly diverted not just chrome registration. Ends justify the means. If i start mozilla, a window should be up and running w/ web page loaded in 2 secs or under. 4.x does. This is all i'm saying. I'm going to do an optimized build off of the branch and see if i can give you more useful comments. Thanks --pete
->hyatt for now
Assignee: trudelle → hyatt
On an optimized build off of the 0.9 Branch it takes 16 seconds. This is with the sidebar. $ time ./mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Registering plugin 0 for: "*","All types",".*" Creating a content listener.. nsBrowserContentListener.init([object Window], [object XULElement] Document http://www.mozilla.org/ loaded successfully ^C real 0m15.983s user 0m14.275s sys 0m0.909s Without the sidebar: real 0m13.079s user 0m11.761s sys 0m0.830s This just plain old sucks man. How does auto chrome registration happen? 1. We check to see if installed-chrome.txt has been recently modified. 2. If it has, then we transverse through all the jar packages for the contents.rdf files. 3. Then we aggregate the contents of those files and create the all-*.rdf files. 4. Then we generate any overlay rdf files. Am i warm? This seems taxing to me. Can't all of this data be put into one lookup rdf file at install time? And everything is created and generated then and pull auto chrome registration out of start up altogether? Dave, am i totally off base here in these assumptions? --pete
Changing summary to: "Chrome Registration needs move out of startup" That will certianly make it quicker. Registration of chrome url's is an installation task. Be it inital installation of mozilla or an additional xpi packages. All we should be doing on startup is reading a gernerated file of registered chrome url's. Thats it. --pete
Summary: Chrome Registration needs to happen quicker → Chrome Registration needs move out of startup
Summary: Chrome Registration needs move out of startup → Chrome Registration needs to move out of startup
We really should get back to having the chrome registry nuke the file once it has been processed. What happens now is that after every install of a new package the chrome registry wades through all the old cruft and re-registers them. This was the old behavior, but was changed for people who messed with their chrome in the optimized tree. If the old behavior of nuking the file is unacceptable maybe we could rename it ("installed-chrome.bak"?). Then the extremely small minority who want this file can rename it back when needed. The Mozilla installer launches into Mozilla immediately, so in effect the chrome registration is done at the end of the install. For an add-on package there's often no need to use the DELAYED_CHROME flag, and thus installed-chrome.txt won't get touched and registration will happen immediately. Packages with XPCOM components *should* use the DELAYED_CHROME flag if having the chrome registered without the components will cause problems. Eventually we'll be able to register components on the fly, too.
Yeah, I agree. The only reason I kept installed-chrome.txt around was for hackers who wanted to hand-edit it. IF it got nuked and regenerated, I wouldn't re-register the world (I'd just register the new package).
What about an environment variable that a XUL hacker could set if they want the ``always re-register'' behavior?
What's wrong with renaming the file out of the way? I wouldn't argue, though, if the default behavior was to delete the file and an optional environment variable was used to say "don't delete after processing". Mac folks might argue, however.
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Target Milestone: Future → ---
chrome registration does not occur on every startup. Ergo, this bug is not a bug. And after 14 months of inactivity, it seems unlikely that we will be changing the model with installed-chrome.txt, etc.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.