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.
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 (
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).
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).
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.
A few more items:
- make a printing mechanism that does not require splitting and is pluggable
- 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.
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.
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
ok, you asked for it :)
here are a few more..
What about bug 179533 (combine mail dlls) ? That would save 550K in footprint,
without sacrificing any functionality.
This bug is about embedding footprint...
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.
Marking dependency on bug #334110. Upgrading to libpng-1.2.10 can save 3-4 kbytes
of library footprint, when PNG encoding is enabled.
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.