[Libreoffice-commits] core.git: editeng: Eliminate unecessary padding in classes
nthiebaud at gmail.com
Wed Nov 4 06:13:23 PST 2015
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
> 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:
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.
It _does_ save some memory.. no matter how small that is compared to
other waste we have, what would be the reason to refuse such patch ?
More information about the LibreOffice