Closed Bug 71249 Opened 24 years ago Closed 23 years ago

change content to use NS_IMPL_NSGETMODULE so it can be combined

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 71248
mozilla0.9.4

People

(Reporter: waterson, Unassigned)

Details

(Keywords: embed, memory-footprint, topembed)

We broke layout and content into their own DLLs, but for packaging purposes, we 
probably want to be able to combine them back. To do that cleanly, we need to 
convert the hand-rolled NS_GetModule() stuff in nsLayoutModule.cpp to use the 
NS_IMPL_NSGETMODULE magic.
See also bug 71248.
Keywords: embed, footprint
Chris, why, why, why? Do we need to do this now?
Target Milestone: --- → mozilla1.0
Well, the jury is out wrt how much space savings we'll get from combining things
together. I'll let you know if this becomes a high priority, for example,
because we discover that megabytes will be saved along with lives.
So did we do pre/post layout split size comparisons? I'm guessing on Mac the 
split added 200-500K.
Although this isn't apples-to-apples, here's a rough comparison for Win32:

[2/15, well before split]
/tmp$ unzip -l embed-win32.zip  | grep gkhtml
  1823744  02-15-01 09:56   Embed/components/gkhtml.dll

[3/1, well after split]
/tmp$ unzip -l embed-win32.zip  | grep gkcon 
  1252000  03-01-01 23:00   Embed/components/gkcontent.dll
/tmp$ unzip -l embed-win32.zip  | grep gklay
   851088  03-01-01 23:00   Embed/components/gklayout.dll

The sum is 2103088 bytes. Assuming nothing else changed (which is patently
false), the split increased the on-disk size by 13% for windows. This may not
correspond to a change to then in-memory size.

On Unix, we can actually look at runtime footprint using the ``size'' command.
Here's what I found:

[2/15]
/tmp/components$ size libgklayout.so 
   text	   data	    bss	    dec	    hex	filename
3231030	 292556	   5436	3529022	 35d93e	libgklayout.so

[3/1]
/tmp/components$ size libgklayout.so libgkcontent.so 
   text	   data	    bss	    dec	    hex	filename
1419784	 112976	  18604	1551364	 17ac04	libgklayout.so
2329545	 204468	   6216	2540229	 26c2c5	libgkcontent.so
3749329  317443   24820 4091593         TOTAL

That's a 16% increase in resident code, 8% increase in static data,
and a 15% increase in size overall. (Again, ass-u-ming no other
changes.)

Ok, maybe this is a big deal!

(Sorry for being too lazy to do this on Mac: sfraser, maybe you could post
equivalent data?)
Taking. Needed so we can link gecko components into a DLL.
Assignee: jst → waterson
Keywords: topembed
Target Milestone: mozilla1.0 → mozilla0.9.4
I'll just put the patches in the other bug.

*** This bug has been marked as a duplicate of 71248 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
QA Contact: nobody → stummala
verified dup
Status: RESOLVED → VERIFIED
Assignee: waterson → nobody
Component: DOM: Abstract Schemas → DOM
QA Contact: stummala → general
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.