Note: There are a few cases of duplicates in user autocompletion which are being worked on.

embedding code size reduction tracking bug



Core Graveyard
15 years ago
a year ago


(Reporter: John Keiser (jkeiser), Assigned: chris hofmann)


(Depends on: 3 bugs, {footprint})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




15 years ago
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

15 years ago
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).
Depends on: 17027, 124412, 139912
Keywords: footprint
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

15 years ago
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.


15 years ago
Hardware: PC → All

Comment 4

15 years ago
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.
Depends on: 21771, 178292
Hardware: All → PC


15 years ago
Hardware: PC → All

Comment 5

15 years ago
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

15 years ago
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

15 years ago
ok, you asked for it :)
here are a few more.. 
Depends on: 170985, 170991, 190729


15 years ago
Depends on: 191489
Depends on: 191800
Depends on: 69996
No longer depends on: 191800
Depends on: 191800
Depends on: 193428


15 years ago
Depends on: 194294


15 years ago
Depends on: 194295


15 years ago
Depends on: 194296


15 years ago
Depends on: 194300


15 years ago
Depends on: 194303


15 years ago
Depends on: 194308

Comment 8

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

Comment 9

15 years ago
This bug is about embedding footprint... 

Comment 10

15 years ago
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.
Summary: code size reduction tracking bug → embedding code size reduction tracking bug


15 years ago
Depends on: 198533
Depends on: 264710
Depends on: 265534
Marking dependency on bug #334110.  Upgrading to libpng-1.2.10 can save 3-4 kbytes
of library footprint, when PNG encoding is enabled.
Depends on: 334110
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.
Depends on: 403239

Comment 13

a year ago
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.
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.