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

[Michael Stahl]

On 04.11.2015 15:13, Norbert Thiebaud wrote:
> On Wed, Nov 4, 2015 at 8:05 AM, Michael Stahl <mstahl at 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.