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

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?

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?

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.

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.

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

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

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

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 .

reassign to 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

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.

mark it as assigned moz0.9.1

nsIEntityConverter is needed by widget and gfx.

mark it as moz0.9.2

move to moz0.9.3

move to future.

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.

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

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

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

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

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

move to m1.0 for any meta bug

meta bug go 1.1

move all my "tracking" bug to "M1"

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

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.

Mass Reassign Please excuse the spam

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

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

old netscape tracking bug, closing