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

[Ashod Nakashian]

On Wed, Nov 4, 2015 at 6:22 AM, Stephan Bergmann <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. As noted
already, padding will waste space if not intentionally accounted for. Of
course member reordering to avoid padding can make readability suffer as
well (we already have heavy public/private interlacing with const/non-const
pairs pages apart).

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.

In any case, optimizations like these should be documented, otherwise it's
not obvious what's intentional and what's accidental.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20151104/b553c082/attachment.html>