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

On Wed, Nov 4, 2015 at 5:22 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
> (And
> reordering members for tighter packaging can even negatively improve
> execution speed in various ways.)

on heavily threaded environment you can have a situation where when
often read variable are too close to often written variable, you get a
significant of spurious cache-line bounce.
these are very rare, and for all intent and purpose, nonexistent in
libreoffice code (due to very poor //-ism to start with)
accidental mis-alignment can, by chance, separate these variables in 2
different cache-line.. but the proper solution is not to add padding,
but to organized
the data with that in mind. and yes _that_ kind of optimization can be
safely ignored until proven otherwise by measurement.

In any case wasted space due to alignment is not a 'good thing', and
the lack of care is a sad state of affair not a 'best practice'.
proper packing of a structure is not an 'optimization', it should be
the default.
btw clang has -Wpadded :-)

the class in question is not the most used one of the sfxItem
category, but still in just tests we run  for lcov, it is still
instantiated mode than 100K times.
the patch in question in 64 bits mode, make the struct fit in 29 bytes
-> rounded to 32  vs  37 before (rounded to 40) that is a 20%
difference and 800K of allocation.
(and yes using 3 plain bool would be better in this case, since we use
the memory anyway even with the bitfield. 29 and 31 both round to 32)

Norbert