delay loading charset dlls at startup

RESOLVED WONTFIX

Status

Core Graveyard
Tracking
P1
normal
RESOLVED WONTFIX
17 years ago
a year ago

People

(Reporter: Cathleen, Assigned: Jungshik Shin)

Tracking

(Depends on: 1 bug, {meta, perf})

Trunk
meta, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nav+perf])

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
trying to improve startup, and delay loading unecessary libraries till later.
(Reporter)

Updated

17 years ago
Blocks: 71781
Keywords: perf

Comment 1

17 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?
(Reporter)

Comment 2

17 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?
(Reporter)

Comment 3

17 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.
(Reporter)

Comment 4

17 years ago
Created attachment 31201 [details]
blank xul window

Comment 5

17 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.
(Reporter)

Comment 6

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

Updated

17 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 7

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

Comment 8

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

Comment 9

17 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 .

Updated

17 years ago
Assignee: ftang → yokoyama
Status: ASSIGNED → NEW

Comment 10

17 years ago
reassign to yokoyama

Comment 11

17 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      

Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1

Comment 12

17 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. 

Assignee: yokoyama → ftang
Status: ASSIGNED → NEW

Comment 13

17 years ago
mark it as assigned moz0.9.1
Status: NEW → ASSIGNED

Comment 14

17 years ago
nsIEntityConverter is needed by widget and gfx. 

Comment 15

17 years ago
mark it as moz0.9.2 
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 16

17 years ago
move to moz0.9.3 
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

17 years ago
Whiteboard: [nav+perf]

Comment 17

17 years ago
move to future.
Target Milestone: mozilla0.9.3 → Future

Comment 18

16 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. 
Target Milestone: Future → mozilla0.9.4
(Reporter)

Updated

16 years ago
Depends on: 96529
(Reporter)

Updated

16 years ago
Depends on: 96530

Updated

16 years ago
Depends on: 96662

Updated

16 years ago
Blocks: 96663

Comment 19

16 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

Comment 20

16 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. 

Updated

16 years ago
No longer blocks: 96663

Updated

16 years ago
Depends on: 96663

Comment 21

16 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

Updated

16 years ago
Depends on: 96525

Updated

16 years ago
Depends on: 96681

Updated

16 years ago
Depends on: 96680

Comment 22

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




No longer depends on: 96525, 96680, 96681
(Reporter)

Updated

16 years ago
Depends on: 96678
(Reporter)

Updated

16 years ago
Depends on: 96680
(Reporter)

Updated

16 years ago
Depends on: 96525, 96681

Updated

16 years ago
Depends on: 97462

Comment 23

16 years ago
reassign to jbetak to take the ownership. move to m0.9.6 it is really a meta bug
now. 
Keywords: meta
Target Milestone: mozilla0.9.4 → mozilla0.9.6

Comment 24

16 years ago
move to m1.0 for any meta bug
Target Milestone: mozilla0.9.6 → mozilla1.0

Updated

16 years ago
Component: Internationalization → Tracking

Updated

16 years ago
Keywords: mozilla1.0

Comment 25

16 years ago
meta bug go 1.1
Target Milestone: mozilla1.0 → mozilla1.1

Comment 26

16 years ago
move all my "tracking" bug to "M1"
Target Milestone: mozilla1.1 → M1

Comment 27

15 years ago
Changing QA contact to bobj for now. Bob, please re-assign further as you see is
appropriate.
QA Contact: andreasb → bobj

Comment 28

13 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.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX

Comment 29

13 years ago
Mass Reassign Please excuse the spam
Assignee: ftang → nobody

Comment 30

13 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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 31

13 years ago
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
old netscape tracking bug, closing
Status: NEW → RESOLVED
Last Resolved: 13 years ago9 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.