Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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.
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 ?

Norbert

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.