17032 - Browser component DLLs should be combined

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect, P1)

Description

[Simon Fraser [no longer active]]

In an effor to reduce the number of small DLLs, we need to combine the browser
component DLLs (which can usefully be combined) into a single larger DLL.

Comment 1

[hamerly]

PDT- should be porkjockey, not dogfood.

Comment 2

[don]

Do this for M12.

Comment 3

[don]

Move to M13 since this is not dogfood.

Comment 4

[Daniel Veditz [:dveditz]]

Keep Simon in the loop as this may conflict with his 5085 where he was talking
about *splitting* libraries (reconfiguring, actually) so less is loaded at
startup.

Comment 5

[don]

Not required for beta 1.

Comment 6

[leger]

Moving "perf" to keyword field.  This is the are we use now :-)

Comment 7

[don]

Move to M16 for now ...

Comment 8

[Simon Fraser [no longer active]]

Judson, do we need to do this too? I still see the following small browser 
component DLLS that could be combined:

AppShellDebug.shlb ?

FindComponentDebug.shlb
mozBrowserDebug.shlb
shistoryDebug.shlb
ucthDebug.shlb
webBrowserDebug.shlb
xferDebug.shlb

Comment 9

[Judson Valeski]

I consolodated those, on all platforms, which I was able to do (without diving 
into law's specialized/complex APP_MODULE_MACRO thing). The list you show 
contains those that weren't easily consolodated or should be left independent as 
they are candidates for replacement by embedding parties.

Comment 10

[Asa Dotzler [:asa]]

adding some nomination keywords.

Comment 11

[Paul Chen]

nav triage team:

Would be very nice, but not critical for beta1. Marking nsbeta1-, more important 
things to work on would be making xpcom startup faster

Comment 12

[Blake Ross]

P1/Future? Strange combination. Any plans for this soon?

Comment 13

[Paul Chen]

nav triage team:

Umm, won't the "static" build get us this?

Comment 14

[Christian Mattar]

Yes, but with the static build, we lose all the advantages of the component 
system. We currently have lots of DLLs (about 90), and I'd bet this number could 
be cut in half without too much pain.

Comment 15

[basic]

Changing platform

Comment 16

[Ryan VanderMeulen [:RyanVM]]

As of Firefox 3.0b2, only two DLLs are in the components directory: browserdirprovider.dll
brwsrcmp.dll

bsmedberg, stuart: Are these DLLs which could go into libxul or are they best off staying separate?

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Oh, and I'm assuming that Seamonkey will be in a similar position once libxul is enabled, yes?

Comment 18

[Benjamin Smedberg]

They should not be in libxul: libxul is the platform by design, and Firefox is built on top of it. You could theoretically combine the two DLLs into one, but it won't affect performance noticably.

Comment 19

[Philip Chee]

WFM:  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110212 Firefox/4.0b12pre SeaMonkey/2.1b3pre

Only suite.dll left