Wanted: footprint reduction ideas

[Alec Flett]

As a part of the continuous push for footprint reduction, I'm trying to
gather a list of larger code changes that we can make to Gecko and
everything that supports Gecko that might make significant (lets say 3%
or more) differences in compiled code size without any significant
reduction in functionality.

I am specifically focusing on reduction of compiled code; this is
independent of the heap reduction effort underway by Cathleen and company.

What kinds of things should you be looking for? There are lots of
possibly-bad patterns that I'm posting to

http://www.mozilla.org/performance/footprint-reduction-techniques.html

The techniques outlined in this document can be applied to any module,
but I'm also looking for architecture changes, and so forth.

Please take a few minutes and read through this document (its large, but
interesting) and see if you recognize any "bad" patterns in your code.
If you find any, just drop me an e-mail and I'll start looking into it.

Here are a few ideas that people have come up with so far (I've gotten
lots more, this is just a sample)

from Darin Fisher:
"nsNetUtil.h (chalk full of inline functions) results in a lot of
duplicate code throughout the product. making this into a shared
library will help reduce code size."

from Jonas Sicking:
"Another thing that i just noticed is that the MAKE_CTOR-macros in
nsContentModule.cpp are creating a lot of almost identical code. They
should be modifyable to create small functions that all call into a
single function that just takes a additional functionpointer as argument."

from Chris Saari:
"We were talking about removing the XPCOM interface model of object
aquisition, query and usage and replacing it with more standard C++
interfaces that would only be accessible from within the module [...]
The problem is that the codebase is highly cross dependent, so crossing
module boundaries occurs very often"

from Kathy Brade:
"I don't know if we can get a disk footprint win or a memory footprint
win for cleaning up some xul and js (are there patterns we can make
available in a generic utilities or overlay file instead of everyone
writing them? is there lots of QI's that could be optimized if done in
one place?)."

Here's what I need from you: If you know any particular module well, I'd
like to hear some general ideas about where to start reducing our code
size.*You do not have to do the work*, measure anything, or provide
proof that the reduction in question will make any difference. I'll file
the bugs and start to evaluate which ideas look the most promising. If
your idea seems particularily worthwhile, I'll come back and pick your
brain to understand what is involved, and the kind of expertise it would
take to pull it off. Finally, I'll start to translate your brain dump
into details in the bugs, so we have a record of what someone would need
to do, and what it could gain us.

As we start to uncover promising candidates, I'll be doing some of the
work myself, and helping others do the work with the information that
you've given me.

Thanks!

Alec

--
Ask me about my 1999 Volkswagen GTI for sale in the San Francisco area!

[Christian Mattar]

Alec Flett wrote:
>
> As a part of the continuous push for footprint reduction, I'm trying to
> gather a list of larger code changes that we can make to Gecko and
> everything that supports Gecko that might make significant (lets say 3%
> or more) differences in compiled code size without any significant
> reduction in functionality.

<snip>

Is there a tracking bug to monitor possible ideas/progress in this case?

Thanks
Christian

[ha shao]

In article <3D932E82...@netscape.com>, Alec Flett wrote:
>
> What kinds of things should you be looking for? There are lots of
> possibly-bad patterns that I'm posting to
>
> http://www.mozilla.org/performance/footprint-reduction-techniques.html
>

Damn the page does not wrap properly and the font is too small.
Could you wrap the long source code lines by hand?

--
Best regard
hashao

[Alfred Kayser]

Alec Flett wrote:
> As a part of the continuous push for footprint reduction, I'm trying to
> gather a list of larger code changes that we can make to Gecko and
> everything that supports Gecko that might make significant (lets say 3%
> or more) differences in compiled code size without any significant
> reduction in functionality.

Good plan, and items mentioned in your document seems promising.
Look also very carefull about 'bloat' functionality.
May be it is time to remove the dreadfull 'quickstart'
functionality and really try to minise the footprint of an 'idle'
gecko/mozilla application/runtime.

Specifically to XUL/CSS/Theming there are some items I can mention:
* Deadcode removal from XUL:
taskbarOverlay.xul is apparently not used anymore

* 'Redundant' code removal from XUL:
* toolbarbutton and button-toolbar are essentially the same?
button-toolbar seems to be used for same 'special' cases of the
toolbarbutton.
* back/forward buttons in navigator and help use the same icons but
are seperately styled (navigator.css: #back, help.css: #backButton,
etc)
* printpreview.css: uses its own type of 'toolbarbuttons'
(toolbar > button)

* merge global and communicator, as most of communicator stuff is used
by other general components.
* merge global and forms? Is it really usefull to be able to apply
different themes to the application and to the 'forms' itself ?
It is even not really possible right now, as there is no UI for
theming per component, and problaby no existing theme can handle it
correctly.

* In another area the 'res' directory can really be cleaned up.
Ok, these are not directly related to gecko itself, but add to the
overall size of mozilla.

Greetings, Alfred

[Axel Hecht]

Alec Flett wrote:
>
<...>
> http://www.mozilla.org/performance/footprint-reduction-techniques.html

Is there a bug about the heap_tables stuff yet?

> Ask me about my 1999 Volkswagen GTI for sale in the San Francisco area!

Not that I'm interested, but isn't something missing here? "Golf", or is
it still "Rabbit" over there? Jetta (was that still produced 1999?)?

Axel

[Peter Trudelle]

Alfred Kayser wrote:

> May be it is time to remove the dreadfull 'quickstart'
> functionality and really try to minise the footprint of an 'idle'
> gecko/mozilla application/runtime.

I agree that we need to minimize the footprint, especially while idle,
but I'm curious why you think Quicklaunch is so dreadful that it needs
to be removed entirely.

Peter

[Jeffrey Siegal]

Axel Hecht wrote:
>>Ask me about my 1999 Volkswagen GTI for sale in the San Francisco area!
>
> Not that I'm interested, but isn't something missing here? "Golf", or is
> it still "Rabbit" over there? Jetta (was that still produced 1999?)?

In the US, at least, "GTI" is the VW model designation for a
performance-upgraded Golf.

[Randell Jesup]

Your comments about switch statements in
http://www.mozilla.org/performance/footprint-reduction-techniques.html
are interesting, but not necessarily correct depending on the compiler
and the switch statement in question.

"Good" compilers will notice that a set of case statements have
consecutive values (or close to), and change the classic switch "if
... else if .... else if ...." code into a indexed lookup that even
faster than your example, since it doesn't have to iterate at all.

For example, the code in nsHTMLContentSink:

switch (aNodeType) {
case eHTMLTag_a:
rv = NS_NewHTMLAnchorElement(..);
break;
case eHTMLTag_applet:
rv = NS_NewHTMLAppletElement(..);
break;
// etc for 73 more tags!
}

could compile down to the equivalent to this (but in asm, of course):

if (aNodeType < eHTMLTag_lowest || aNodeType > eHTMLTag_highest)
{
// default case
switch_table_2:
// there was a hole in the case list

rv = NS_OK;
}
else
{
goto switch_table[aNodeType - eHTMLTag_lowest];
switch_table_0:
rv = NS_NewHTMLAnchorElement(..);
goto end;
switch_table_1:
rv = NS_NewHTMLAppletElement(..);
goto end;
switch_table_3:
rv = NS_NewHTMLBRElement(..);
goto end;
[etc]
}
end:

This isn't that unusual an optimization; SAS C/C++ for the 680x0 (Amiga,
etc) had it back around 1990 or before.

Also, good optimizers (again, SAS C did this) will convert a long series of
if-elseif-elseif's that kill a processor cache into a table-search and
jump, probably even being tricky and for large switch statements using a
binary search. Much more efficient than the linear search.

Also, some good optimizers (including GCC, which isn't great) will notice
that (for example) all or several cases end with the same or similar code
and combine them; which it may not do if they're seperate routines. (In
this example above, you're helped by the fact that each case only calls a
single function with the same signature).

--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
rje...@wgate.com
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania, 1759.

[Randell Jesup]

Randell Jesup <rje...@wgate.com> writes:
>could compile down to the equivalent to this (but in asm, of course):
>
> if (aNodeType < eHTMLTag_lowest || aNodeType > eHTMLTag_highest)
> {
> // default case
>switch_table_2:
> // there was a hole in the case list
>
> rv = NS_OK;
> }
> else
> {

>[etc]
> }
>end:

I'll pick a minor nit in my own posting: for very very slightly
better performance in some cases, it probably would reverse that if
statement and put the default case at the end.

(I used to beta-test compilers in my spare time, especially their optimizers)

[Casey]

Here's a link that my help speed things up a bit. It's primarily
focused on JavaScript, but the techniques can be applied to any
language.

http://home.earthlink.net/~kendrasg/info/js_opt/jsOptMain.html

[BrendaEm]

Why not prune the entire non-Chimera OS X version of Mozilla and just
work on Chimera instead?

I use the Win32 version of Mozilla. It works in the operating system
for which it was designed. Chimera works for OS X, but the non-Chimera
version is not really native is it?

Chimera is branched a little ways off the trunk, but I think that
Chimera has a better chance for adoption than the non-optimised
version.

I have a lot of friends who us Macs. I have been trying to get them to
change to from IE to Chimera. I don't think I could get them to use a
non-native version as easily.

I am sure that a lot of effort went into the non-Chimera version of
Mozilla. I respect that. Merges also seem rare in the open-source
community, and I find that very dissapointing. I don't want anyone's
work lost.

Yet, I want the Mac version of Mozilla to be popular, and this seems
the best way.

Brenda