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

[Michael Stahl]

On 04.11.2015 13:46, Ashod Nakashian wrote:
> 
> On Wed, Nov 4, 2015 at 6:22 AM, Stephan Bergmann <sbergman at redhat.com
> <mailto:sbergman at redhat.com>> wrote:
> 
>     On 11/04/2015 12:03 PM, Norbert Thiebaud wrote:
> 
>         imo intentional mis-alignment should be heavily documented as such.
> 
> 
>     I would assume "non-optimal" padding to occur frequently enough to
>     just not care about it, unless there is indication that it severely
>     affects performance.  Padding requirements can vary among platforms
>     (e.g., due to differences in integer width types or differences in
>     typedefs) and over time (e.g., when a member changes type or a
>     member's type changes).  (And reordering members for tighter
>     packaging can even negatively improve execution speed in various
>     ways.)  So I would rather assume cases to be heavily documented
>     where order is deliberately chosen to avoid padding.
> 
> It seems to me bit-fields are a bit overused. We should only need it in
> the most heavily instantiated of classes and where there are too many
> flags to make it worthwhile. For all other cases we're paying a cost in
> terms of performance and maintainability with little footprint gains.

surprisingly contemporary compilers may even still have optimization
bugs related to bit fields,
cf. clang 3.5 mangling SvRefBase:  http://fpaste.org/285206/

> FWIW, I'd make most classes (esp. heavily used but not heavily
> instantiated) to be human-intuitive first, while, for those that can
> benefit, order members by size (largest first) and bitfields for flags.

agreed - profile first, then optimize where it's slow.