Last Comment Bug 191033 - embedding code size reduction tracking bug
: embedding code size reduction tracking bug
: footprint
Product: Core Graveyard
Classification: Graveyard
Component: Tracking (show other bugs)
: Trunk
: All All
-- normal with 3 votes (vote)
: ---
Assigned To: chris hofmann
: chris hofmann
Depends on: 21771 139912 170991 17027 69996 124412 170985 178292 190729 191489 191800 193428 194294 194295 194296 194300 194303 194308 198533 264710 265534 334110 403239
  Show dependency treegraph
Reported: 2003-01-28 15:44 PST by John Keiser (jkeiser)
Modified: 2016-07-15 12:13 PDT (History)
26 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image John Keiser (jkeiser) 2003-01-28 15:44:09 PST
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 User image John Keiser (jkeiser) 2003-01-28 16:30:58 PST
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 ( ).

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 User image Brian Ryner (not reading) 2003-01-28 17:01:03 PST
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 User image John Keiser (jkeiser) 2003-01-29 15:56:48 PST
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 User image John Keiser (jkeiser) 2003-01-30 12:04:42 PST
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 User image Alec Flett 2003-01-30 13:04:38 PST
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 User image John Keiser (jkeiser) 2003-01-30 14:33:16 PST
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 User image Alec Flett 2003-01-30 15:24:00 PST
ok, you asked for it :)
here are a few more.. 
Comment 8 User image Jo Hermans 2003-02-21 13:22:58 PST
What about bug 179533 (combine mail dlls) ? That would save 550K in footprint,
without sacrificing any functionality.
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2003-02-21 13:29:45 PST
This bug is about embedding footprint... 
Comment 10 User image Alec Flett 2003-02-21 14:27:02 PST
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 User image Glenn Randers-Pehrson 2006-05-31 08:08:08 PDT
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 User image Glenn Randers-Pehrson 2007-11-09 20:48:30 PST
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 User image BMO Automation 2016-07-01 13:04:04 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.