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

On 04.11.2015 15:13, Norbert Thiebaud wrote:
> On Wed, Nov 4, 2015 at 8:05 AM, Michael Stahl <mstahl@redhat.com> wrote:
> > On 04.11.2015 13:56, Norbert Thiebaud wrote:
> > > 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.
> >
> > thanks for measuring that, across 1000 or so document load then store
> > then load again operations in Writer unit tests alone it's entirely
> > negligible.
> >
> > much better to invest time in tracking down the copious memory leaks
> > with LSAN or valgrind.
>
> no time at all, just looking at existing data:
> http://lcov.libreoffice.org/editeng/source/items/frmitems.cxx.gcov.html
>
> But really the issue is: a volunteer scratch his itches and send a
> patch about a wasteful padding.
> I have not seen anyone argued that the moving of a uint16_t 3 slot
> below in this 32/40 byte structure is causing any readability harms,
> or hurt performance.

i think it's fine in this case, i just don't want people to feel
encouraged to send 10 patches like this every day.

oh and while i'm looking at it, a much bigger problem in that
SvxLRSpaceItem class is pointless use of "long" variables - these are
used all over the place and are a relic of when "int" variables were
just 16 bits; now they eat up 64 bits when 32 would be more than enough.