On 04.11.2015 15:13, Norbert Thiebaud wrote: > On Wed, Nov 4, 2015 at 8:05 AM, Michael Stahl <mst...@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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
