75041 - delay loading charset dlls at startup

Status: RESOLVED WONTFIX

(Core Graveyard :: Tracking, defect, P1)

Description

[Cathleen]

trying to improve startup, and delay loading unecessary libraries till later.

Comment 1

[Frank Tang]

cathleen- I really do not understand this bug. Could you explain? We already 
delay loading charset dll untill we need it. Could you explain to us which one is 
unnecessary and when it get loaded when it is unnecessary?

Comment 2

[Cathleen]

Frank, if I'm understanding correctly, you're already delay loading all of 
charset and it's related dlls?  that's great!   Was it done after 4/2?

Comment 3

[Cathleen]

chardet.dll      
uconv.dll
ucharuti.dll      
urildr.dll   

are not being late loaded till they're requested, as of win32 4/17 build.  
even if you're opening a blank xul window.

I'll be attaching my test case xul file to this bug.
save test xul file locally (e.g. in c:\temp), then run either

mozilla -chrome file:/c:/temp/minimal.xul
netscp6 -chrome file:/c:/temp/minimal.xul

download taskinfo2000 to get data on the entire list of dlls loaded by the app.

Comment 4

[Cathleen]

Attachment: blank xul window

Comment 5

[Frank Tang]

we need to load uconv.dll to display a blank xul window since it is a xml file 
and we need to convert the default encoding for xml (which is utf-8) to 
PRUnichar*. That convrsion is implemented inside uconv.dll

I have no clue what is urildr.dll   at all. Not my component, sorry.

I think the reason chardet.dll get load is because we have the meta charset 
service init code somewhere. yokoyama is working on remove that. Probably we can 
solve this issue. 

I will take a look at ucharuti.dll loading.

Comment 6

[Cathleen]

sorry urildr is for uri loader.... I miss read uri->uni.  :o)

Comment 7

[Cathleen]

hey frank, are you still looking at this?  I need a commitment target milestone. 
thanks! :-)

Comment 8

[Cathleen]

frank, are you still working on this? I need some traction on this bug, to help 
improve startup performance.  -thanks

Comment 9

[Frank Tang]

roy- can you help to find out why we load chardet.dll (does that get addressed 
after you check in the meta charset service change?)
also, can you help us find out where do we load ucharuti.dll?
We may need both .

Comment 10

[Frank Tang]

reassign to yokoyama

Comment 11

[Roy Yokoyama]

ftang: the meta charset service is already checked in for the moz0.9 milestone.
I'll take a look for both:
chardet.dll      
ucharuti.dll      

Comment 12

[Roy Yokoyama]

ftang: Here is what I found.
First of all, I verified that chardet.dll and ucharuti.dll
get loaded at startup (20010514 build).

chardet.dll
  In this dll, we expose quite number of interfaces
  which may be required at startup.
   - nsIXMLEncodingService
   - nsIMetaCharsetService
   - nsIDocumentCharsetInfo
   - nsICharsetDetector
   - nsICharsetDetectionObserver
   - nsICharsetDetectionAdaptor
   - nsIStringCharsetDetector

ucharuti.dll
  In this dll, we expose the following Interfaces
    - nsIEntityConverter
    - nsISaveAsCharset
  I think we can delay the SaveAsCharset part; but not sure
  about the EntityConverter.

I think I am missing an overall picture of when we need these dlls.
It may be better if you can own this bug, frank. 

Comment 13

[Frank Tang]

mark it as assigned moz0.9.1

Comment 14

[Frank Tang]

nsIEntityConverter is needed by widget and gfx. 

Comment 15

[Frank Tang]

mark it as moz0.9.2 

Comment 16

[Frank Tang]

move to moz0.9.3 

Comment 17

[Frank Tang]

move to future.

Comment 18

[Frank Tang]

ok, I am wrong, we should look into this in the 94 time frame
the reason unicharutil load into memory is because
nsString case conversion call it, I think we could do a optimization for the
ASCII only case. 

Comment 19

[Frank Tang]

ok, now I am looking at the following dlls:

chardet
unicharutil
strres
nslocale
uconv

here are the first result
unicharutil.dll won't be load into memory for blank.xul if we check in 96529, 96530

Comment 20

[Frank Tang]

chardet is currently load into memroy by
nsAppStartupNotifier::Observe . It will be tricky to remove it from there. but I
will research it later. 

Comment 21

[Frank Tang]

nslocale is currently loaded into memory by the following places:

96662 nsXULContentUtils::Init <= we can address this one
96663 nsPresContext.cpp <= hard to address this one.
96680 nsScriptSecurityManager::InitPrincipals
96681 nsHttpHandler::InitUserAgentComponents()
96678 nsPrefBranch::GetDefaultFromP

Comment 22

[Frank Tang]

strres is currently load into memory by:
96525 nsProfile.cpp
96680 nsScriptSecurityManager::InitPrincipals
96681 nsHttpHandler::InitUserAgentComponents()
96678 nsPrefBranch::GetDefaultFromP

Comment 23

[Frank Tang]

reassign to jbetak to take the ownership. move to m0.9.6 it is really a meta bug
now. 

Comment 24

[Frank Tang]

move to m1.0 for any meta bug

Comment 25

[Frank Tang]

meta bug go 1.1

Comment 26

[Frank Tang]

move all my "tracking" bug to "M1"

Comment 27

[Andreas Becker]

Changing QA contact to bobj for now. Bob, please re-assign further as you see is
appropriate.

Comment 28

[Frank Tang]

what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.

Comment 29

[Travis Chase]

Mass Reassign Please excuse the spam

Comment 30

[Travis Chase]

Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him

Comment 31

[Travis Chase]

Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam

Comment 32

[Matthias Versen [:Matti]]

old netscape tracking bug, closing