Re: [Libreoffice-commits] core.git: editeng: Eliminate unecessary padding in classes

On 11/04/2015 11:21 AM, Norbert Thiebaud wrote:
> On Wed, Nov 4, 2015 at 3:42 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
> > On 11/04/2015 09:16 AM, Daniel Robertson wrote:
> > >    class EDITENG_DLLPUBLIC SvxLRSpaceItem : public SfxPoolItem
> > >    {
> > > -    short   nFirstLineOfst;     // First-line indent _always_ relative to
> > > nTxtLeft
> > >        long    nTxtLeft;           // We spend a sal_uInt16
> > >        long    nLeftMargin;        // nLeft or the negative first-line
> > > indent
> > >        long    nRightMargin;       // The unproblematic right edge
> > >
> > >        sal_uInt16  nPropFirstLineOfst, nPropLeftMargin, nPropRightMargin;
> > > +    short   nFirstLineOfst;     // First-line indent _always_ relative to
> > > nTxtLeft
> >
> >
> > With micro-optimization changes like these, I would leave it to some domain
> > expert to decide whether it is actually worth it (i.e., whether on the one
> > hand the existing member order had been chosen deliberately, to aid human
> > comprehension, and whether on the other hand enough instances of that class
> > are created to warrant any such optimization).
>
> Domain expert are the last one to reliably evaluate 'human
> comprehension", since they _are_ domain expert
> wrt to the number of instance... even if there is only one. is it a
> reason to be sloppy ?

What is sloppy about a set of members sorted due to some rationale?  (I 
do not argue whether or not the members in this specific case were 
sorted due to such a rationale.  I just want to avoid such random 
micro-space-optimizations in the future to break well-founded orders.)

> > >        bool        bAutoFirst  : 1;    // Automatic calculation of the
> > > first line indent
> > > -    bool        bExplicitZeroMarginValRight;
> > > -    bool        bExplicitZeroMarginValLeft;
> > > +    bool        bExplicitZeroMarginValRight : 1;
> > > +    bool        bExplicitZeroMarginValLeft : 1;
> >
> >
> > It is unclear whether that is an optimization or a pessimization.
>
> you can choose size or perf.. but having a
> bool foo:1
> followed by 2 plain bool
> is wrong either way.

Yes, that is arguably something to clean up.  The question is just which 
way to clean it up makes more sense.  (Especially as a series of three 
non-bitfield bool can be a performance optimization over a series of 
three size-1-bitfield bool without being a space pessimization.)