Cathleen Reporter
	Description • 24 years ago

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

	Frank Tang
	Comment 1 • 24 years ago

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?

	Cathleen Reporter
	Comment 2 • 24 years ago

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?

	Cathleen Reporter
	Comment 3 • 24 years ago

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.

	Frank Tang
	Comment 5 • 24 years ago

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.

	Cathleen Reporter
	Comment 6 • 24 years ago

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

	Cathleen Reporter
	Comment 7 • 24 years ago

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

	Cathleen Reporter
	Comment 8 • 24 years ago

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

	Frank Tang
	Comment 9 • 24 years ago

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 .

	Frank Tang
	Comment 10 • 24 years ago

reassign to yokoyama

	Roy Yokoyama
	Comment 11 • 24 years ago

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      

	Roy Yokoyama
	Comment 12 • 24 years ago

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. 

	Frank Tang
	Comment 13 • 24 years ago

mark it as assigned moz0.9.1

	Frank Tang
	Comment 14 • 24 years ago

nsIEntityConverter is needed by widget and gfx. 

	Frank Tang
	Comment 15 • 24 years ago

mark it as moz0.9.2 

	Frank Tang
	Comment 16 • 24 years ago

move to moz0.9.3 

	Frank Tang
	Comment 17 • 24 years ago

move to future.

	Frank Tang
	Comment 18 • 23 years ago

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. 

	Frank Tang
	Comment 19 • 23 years ago

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

	Frank Tang
	Comment 20 • 23 years ago

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

	Frank Tang
	Comment 21 • 23 years ago

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

	Frank Tang
	Comment 22 • 23 years ago

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

	Frank Tang
	Comment 23 • 23 years ago

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

	Frank Tang
	Comment 24 • 23 years ago

move to m1.0 for any meta bug

	Frank Tang
	Comment 25 • 23 years ago

meta bug go 1.1

	Frank Tang
	Comment 26 • 23 years ago

move all my "tracking" bug to "M1"

	Andreas Becker
	Comment 27 • 22 years ago

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

	Frank Tang
	Comment 28 • 20 years ago

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.

	Travis Chase
	Comment 29 • 20 years ago

Mass Reassign Please excuse the spam

	Travis Chase
	Comment 30 • 20 years ago

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

	Travis Chase
	Comment 31 • 20 years ago

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

	Matthias Versen [:Matti]
	Comment 32 • 16 years ago

old netscape tracking bug, closing