Chrome Registration needs to move out of startup




18 years ago
15 years ago


(Reporter: pete, Assigned: jag+mozilla)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nav+perf])



18 years ago
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.



18 years ago
Keywords: perf

Comment 1

18 years ago
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

Comment 2

18 years ago
I think a good solution would be to register everything as a final step at
install time. A cheat but a nice one.



Comment 3

18 years ago
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.


Comment 4

18 years ago
> 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?


Comment 5

18 years ago
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

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.



Comment 6

18 years ago
->hyatt for now
Assignee: trudelle → hyatt

Comment 7

18 years ago
On an optimized build off of the 0.9 Branch it takes 16 seconds.
This is with the sidebar.

$ time ./mozilla
./ ./mozilla-bin
Registering plugin 0 for: "*","All types",".*"
Creating a content listener..
nsBrowserContentListener.init([object Window], [object XULElement]
Document loaded successfully

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?



18 years ago
Target Milestone: --- → Future

Comment 8

18 years ago
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.

Summary: Chrome Registration needs to happen quicker → Chrome Registration needs move out of startup


18 years ago
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 

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.

Comment 10

18 years ago
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).

Comment 11

18 years ago
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.


18 years ago
Whiteboard: [nav+perf]

Comment 13

17 years ago
--> default owner
Assignee: hyatt → jaggernaut
Target Milestone: Future → ---

Comment 14

17 years ago
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.
Last Resolved: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.