77375 - Chrome Registration needs to move out of startup

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Pete Collins (MDG)]

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

Comment 1

[Chris Waterson]

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.

Comment 2

[Pete Collins (MDG)]

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

;-)

--pete

Comment 3

[Pete Collins (MDG)]

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

Comment 4

[Chris Waterson]

> 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

[Pete Collins (MDG)]

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

Comment 6

[Peter Trudelle]

->hyatt for now

Comment 7

[Pete Collins (MDG)]

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

Comment 8

[Pete Collins (MDG)]

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

Comment 9

[Daniel Veditz [:dveditz]]

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.

Comment 10

[David Hyatt]

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

[Chris Waterson]

What about an environment variable that a XUL hacker could set if they want the 
``always re-register'' behavior?

Comment 12

[Daniel Veditz [:dveditz]]

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.

Comment 13

[David Hyatt]

--> default owner

Comment 14

[John Morrison]

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.