[Libreoffice-commits] core.git: editeng: Eliminate unecessary padding in classes
mstahl at redhat.com
Wed Nov 4 06:10:28 PST 2015
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.
More information about the LibreOffice