On Wed, Nov 4, 2015 at 8:05 AM, Michael Stahl <[email protected]> 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 _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
