49527 - Combined core i18n libraries into one library

Status: RESOLVED DUPLICATE of bug 169498

(Core :: Internationalization, defect, P2)

Description

[Doug Turner (:dougt)]

Frank,

i18n has the largest group of component dll's.  Could we reduce this by
combining these libraries into one or two libraries?


bin/components/libchardet.so
bin/components/liblwbrk.so
bin/components/libnslocale.so
bin/components/libstrres.so

bin/components/libuconv.so
bin/components/libucvcn.so
bin/components/libucvibm.so
bin/components/libucvja.so
bin/components/libucvko.so
bin/components/libucvlatin.so
bin/components/libucvtw.so
bin/components/libucvtw2.so

Comment 1

[Frank Tang]

dougt, the reason we break down these into different dlls is then they do not 
need to be load when they are not needed. For example, if the user didn't view a 
Japanese document in this section, then won't need to load libucvja.so . From my 
point of view, combining them together will INCREASE your footprint, not reduce 
it. 
I don't understand why we now decompontize what we spend a lot of efforts to 
componentize in the last two years. 

What is the overhead of a sepeate DLL. What is the criteria for a good SIZE dll?

Comment 2

[Frank Tang]

cc bobj, dp and sfraser-
dp- Is there a paper specify the guideline about how compontize our dll should 
be ? 

Comment 3

[Suresh Duddi (gone)]

No Frank. There is no guidelines for this. Maybe you can write one.

I agree with your agrument. The caveat is that we already load a bunch of these 
dlls at startup no matter what. It is a null brainer to put them all into one 
dll.

I dont think you should put CJK converters into that dll. For now my guideline 
would be get one intl dll loaded for the default startup for latin1 and have as 
many as you like for the rest.

What do you think ?

Comment 4

[Judson Valeski]

why wouldn't the japanese ability be an option? do we ship it to english users?

~32k bytes are associated w/ each lib we load (on linux). you're right frank, 
we're doing consolodation now after componentizing everything because we're 
coming to the realization that componentization has it's drawbacks.

Which of these can we combine?

Comment 5

[bobj]

We don't want to combine the various converters into a single DLL.
Why should users of one of language have to take the fooprint of the
other converters that may not be used?

It's probably reasonable to combine core I18N funtionality into 1 DLL, such as:
  bin/components/libchardetc.so (what is this?)
  bin/components/libchardet.so
  bin/components/liblwbrk.so
  bin/components/libnslocale.so
  bin/components/libstrres.so
  bin/components/libuconv.so
  bin/components/libucvlatin.so

That's a saving of ~32KB x 6 components...

Comment 6

[Judson Valeski]

here's a bug that was filed that implies 100k of bloat after i18n libs were 
built http://bugzilla.mozilla.org/show_bug.cgi?id=7748 . Exactly! why do we ship 
all these other languages (or do we?) if some users will never use them. Let's 
combine what we can.

Comment 7

[Frank Tang]

I do not agree. For a Japanese user, the current dll package will let him load 
only the Japanese converer, but not Chinese nor Korean. IF we combine them 
together, then Japanese user will load Chinese/Korean converter into the memroy.

Comment 8

[Frank Tang]

I suggest we nsbeta3- this. 

Comment 9

[Jaime Rodriguez, Jr.]

Marking nsbeta3- per I18N Bug Triage.

Judson - Please meet with Ftang to discuss a workaround for embedding.

Comment 10

[Judson Valeski]

frank, can you please provide a list of modules that you believe can be 
combined (or should I use the list in here already?)? I will then do the work to 
combine them. thank you.

Comment 11

[Judson Valeski]

asking for reconsideration.

Comment 12

[Frank Tang]

add tao to the cc.
We should be careful here. I remember there are some dependency issue here. 
installer is depend on some of these, and combine them may increase the size of 
installer. Is that true, tao? or they change the design later ?
IF there are no dependency issue, then the last list bobj proposed is good. 

I saw how we grow libi18n from 1.x to 4.x . It is very hard to break it down 
once you combine them. If we combine them, I really don't want to see we need 
spend efforts to break them again later for 7.0 , 8.0, etc. 

Why don't you merge layout and necko together ? or parser and layout ? What is 
the justification here ?

Comment 13

[Judson Valeski]

necko is already condensed, parser and layout are being consolodated too.

Comment 14

[Frank Tang]

If that is the case, I have no problem to combine the list bobj suggest.

Comment 15

[Jaime Rodriguez, Jr.]

Marking as nsbeta3- per I18N Bug Triage.  This is more than a engineering fix,
it is major change  2 1/2 weeks before we have to hit zarro boogs . . . way too
risky, and would require intensive QA.

Comment 16

[Erik van der Poel]

Roy, I'm reassigning this to you.

Comment 17

[Frank Tang]

This could also address some footprint issue. mark this as moz 0.9. I think this
will also impact window since window also have per dll base overhead. The impact
probably is smaller than Linux.

Comment 18

[Roy Yokoyama]

Updating the target milestone.

Comment 19

[Roy Yokoyama]

*** Bug 17029 has been marked as a duplicate of this bug. ***

Comment 20

[Roy Yokoyama]

Now the 2nd stage (65685) is completed (1st stage: 22921), we are ready for 
this bug.  We will combine the following DLLs into one DLL.
{uconv.dll, chardet.dll, nslocale.dll, strres.dll and lwbrk.dll}.  We will call 
the new DLL to be nsi18n.dll.  This will be the only DLL required for English 
users.  Other DLLs such as ucvja.dll, ucvko.dll, ... are for FarEast users and 
ucvlatin.dll is for East European users.

Comment 21

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 22

[Roy Yokoyama]

Focus on bug fix until 6.5

Comment 23

[Stephen Walker]

*** This bug has been marked as a duplicate of 169498 ***