On Wed, Nov 4, 2015 at 5:22 AM, Stephan Bergmann <sberg...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
