On 04.11.2015 13:46, Ashod Nakashian wrote: > > On Wed, Nov 4, 2015 at 6:22 AM, Stephan Bergmann <[email protected] > <mailto:[email protected]>> 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. _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
