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.
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).
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 (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.
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 just yet).
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.
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.