191033 - embedding code size reduction tracking bug

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, defect)

Description

[John Keiser (jkeiser)]

Code size currently accounts for about 70% of the memory we take up on a typical
mfcembed (minimal embedding) run.  This is a tracking bug for suggestions on how
to reduce that footprint for embedders.  Suggestions for things that can
realistically be taken out into modules, major redundancies that can be reduced,
features that can be factored out or at least ifdef'd (this is a less attractive
solution as it doesn't jibe well with GRE), libraries that we can stop linking
to (that increases our memory requirements), compiler flags we can use ...

An analysis shows that the content+layout DLL takes something like 30% of our
code bloat, so it's not a bad place to start.

Comment 1

[John Keiser (jkeiser)]

My suggestions:

1. Split out xul, xbl, svg and mathml into separate dlls that are only loaded
when needed. A first step to this is to make nsCSSFrameConstructor pluggable
(bug 139912, roughly). Also important is taking the XUL box model reflow out of
XUL or else taking the current HTML elements that use it and using the normal,
horrid Reflow method instead.

2. Find dead code (bug 17027). Form control layout has a lot of this. A full
code analysis of what code is reached and what code is not reached would help a
lot here.  Rational's PureCoverage might help with this (
http://www.rational.com/products/purecoverage_unix/index.jsp?SMSESSION=NO ).

3. Load less libraries. Haven't investigated enough here, but we are responsible
for a lot of the symbols loaded from mfc, for example. Are we using all that stuff?

bz also suggested the nsXULDocument / nsDocument code duplication (bug 124412).

Comment 2

[Brian Ryner (not reading)]

XBL is used internally for keybindings, I don't think it's worth making that
library dynamically loaded.

For the others, if we go that route, let's _please_ make these libraries link
against gklayout so we don't have to use XPCOM interfaces (yes, I know this is
difficult on some platforms, but we can come up with something).

Comment 3

[John Keiser (jkeiser)]

Linking against it is absolutely, perfectly fine.  The only requirement in my
mind is that they not load when layout loads, but instead can be loaded on demand.

Comment 4

[John Keiser (jkeiser)]

A few more items:
- make a printing mechanism that does not require splitting and is pluggable
(bug 178292)
- split out so you can not have XHTML or XML (drop XML parser and XML content
sink) or not have HTML (drop HTML parser / HTML content sink) (no real bug, but
bug 21771 is related)
- make history, RDF and mork optional (entails making history, bookmarks pluggable)
- start removing inline functions and see if they actually affect performance

It may be best to #ifdef some of these things out in an initial cut,
specifically get #ifdef XUL working again.

Comment 5

[Alec Flett]

I'm really wondering the value of this tracking bug - as I'm filing bugs faster
than they can be tracked here. there already is a 'footprint' keyword that you
can query on

on that note, history is already pluggable, and thus mork is not required. (it
has been this way for years! Embedded builds have their own "history lite")

bookmarks is kind of pluggable, at least in that it is not required at runtime,
just at build time.

RDF is huge, and I have a tracking bug for that, it involves changing .jar file
and chrome registry format.

Comment 6

[John Keiser (jkeiser)]

The value of this bug is to have a place to discuss the issue in general and
make suggestions.  We could always do it in blogs, but a bug is easier to
revisit.  Plus, of course, it allows me to track issues more easily (dunno if
it's useful to others--all are welcome to post issues--but let's not close it
just yet).

Comment 7

[Alec Flett]

ok, you asked for it :)
here are a few more.. 

Comment 8

[Jo Hermans]

What about bug 179533 (combine mail dlls) ? That would save 550K in footprint,
without sacrificing any functionality.

Comment 9

[Boris Zbarsky [:bzbarsky]]

This bug is about embedding footprint... 

Comment 10

[Alec Flett]

hey john - I'm curious where you got the 70% number.. mostly so that we can
continue to measure that as we pare down both static and dynamic footprint.

Comment 11

[Glenn Randers-Pehrson]

Marking dependency on bug #334110.  Upgrading to libpng-1.2.10 can save 3-4 kbytes
of library footprint, when PNG encoding is enabled.

Comment 12

[Glenn Randers-Pehrson]

Marking dependency on bug #403239.  This removes about 11 kbytes of unused warning and error text from libpng.  I looked at zlib and jpeg but not much could be saved using this method in those libraries.

Comment 13

[BMO Automation]

Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.