89402 - Reorder class/struct data members to make them smaller

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, defect)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

According to the C and C++ language specs the compilers are not allowed to align
class/struct data members to optimize for size. That job is left to the
developer. It seems that there would be some optimization to do in the Mozilla
code base.

Depending on the specific cases, the savings can be significant. The below
sample program illustrates that by showing that class B takes 50% more space
than class A although they have the exact same data members.

Output from program:

long=4, char=1
A=8, B=12 

Source:

#include "stdio.h"

class A {
  long a;
  char b;
  char c;
  char d;
};

class B {
  char b;
  long a;
  char c;
  char d;
};

int main(int argc, char* argv[])
{
  printf ("long=%d, char=%d\n",sizeof(long),sizeof(char));
  printf ("A=%d, B=%d\n",sizeof(A),sizeof(B));
  return 0;
}

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I am not sure who should own this, Cc:ing some people who might want this... If
there are no volunteers you can assign to me.

Best way would probably be to write a script that goes through the tree (or at
least dist), count & store the sizes of each class, and write out the members in
the optimized order. No doubt some handwork required...

Comment 2

[timeless]

just pushing this out of asa's queue, until Heikki accepts the bug the 
assignment doesn't indicate heikki's intention to work on it.

would it be possible/reasonable to write a script which calculates optimal 
(byte alignment), minimal (dword alignment), and perhaps actual (based on 
class/struct def) sizes?  I might be able put together some perl which tries to 
do this.  The first problem of course is that some fields are #if'd, but that 
could be handled by outputting extra numbers.  If the script is small/sane+fast 
enough perhaps we could add 'footprint' numbers to the tinderbox reports (this 
would be based on parsing preprocessed headers and a small def to indicate 
sizes of basic types).

Comment 3

[Scott Collins]

It is possible to write such a script, however it requires a lot of parser like
knowledge.  Perhaps you could start with linker output or something to avoid
needing to be smart.  In general the ordering is easy, go from largest to
smallest.  Within this, you probably want a stable sort from the original
ordering.  Pointers must be considered to be larger than |PRInt32|s, so that the
results are applicable on all platforms.

Your script will want to take into account changed sizes of structured members,
and look out for the impact of member re-ordering on constructor initialization
order.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I did a little investigation with the content and layout directories. In short,
it is wortwhile but not crucial: the savings are most likely to be in large
classes that we have relatively few in memory at any one time (because small
frequently used ones have usually been optimized already). 

Because of this I am futuring this bug. Feel free to take this.

This task should be combined with other optimizations, like packing variables
into as little space as possible (16-bit instead of 32-bit variables if
possible, booleans collected into one variable so each boolean takes only 1 bit
and so on). This kind of work will yield better results than mere reordering. It
also makes sense to combine these two tasks since one you are most likely going
to be hand-editing the class declarations anyway (or spend considerable amount
working on the scripts so you can trust them).

I did this experiment by writing a small Perl script that had simple heuristics
to collect potential classes and file names, which I put into a small C++
program to calculate the sizes. I then looked at each potential class, and
edited the ones that I thought could be optimized just by reordering. I will
attach these tools. They would need a bit more tuning before attacking the full
source to reduce manual labor. 

Note that I did NOT check .cpp files, although I know a lot of them contain
class declarations.

Detailed findings in content and layout directories:

Total number of files scanned: 249 (header files only)
Number of potential classes:    34 (14% of # of files)
Number of optimized classes:     3 (1% of # of files, 9% of potentials)

Of the optimized:
Average optimization (bytes):   16      
Average optimization (%):        3

Content:        
                          Old   New
nsPrivateTextRange        20    -
nsXMLContentSink          288   -
nsStyleLinkElement        20    -
nsXBLBinding              40    -
nsStyleSides              20    -
nsDOMEvent                88    -
nsEventListenerManager    48    -
nsPrivateTextRangeList    20    -
nsXULDocument             436   -
nsROCSSPrimitiveValue     52    -

Layout:

nsMenuFrame               212   -
nsListControlFrame        236   228 (-8 bytes = -3%) 
nsBlockReflowContext      140   -
nsFrameImageLoader        96    -
nsSimplePageSequenceFrame 136   -
nsPresContext             436   416 (-16 bytes = -4%)
nsXULTreeGroupFrame       184   -
nsBlockReflowState        424   -
RoundedRect               28    -
nsGfxTextControlFrame2    192   -
nsImageFrame              140   -
nsInlineFrame             56    -
nsCaret                   100   -
nsFrame                   44    -
nsScrollBoxFrame          164   -
nsXULTreeOuterGroupFrame  264   -
nsLineLayout              1100  1076 (-24 bytes = -2%)
nsTextTransformer         296   -
nsTableOuterFrame         76    -
nsTableFrame              104   -
nsComboboxControlFrame    232   -
nsCSSRendering            1     - (this is weird, no data members)
nsFormFrame               260   -

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: findpotentials.pl

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: sizecalculator.cpp

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: makefile.win for sizecalculator.cpp

Comment 8

[Cormac F]

Adding meta keyword - Sorry for the spam!

Comment 9

[BMO Automation]

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.