On 25/09/2020 07:57, Noel Grandin wrote: > No, just the merged library. I would suspect that LTO is most useful when focused with a profile or two - warm startup, loading blank documents etc. Is there a way to inject one into the process? Also - I would expect that the biggest wins from LTO would come from inlining things like the sal/ string classes, and cleaning up atomic reference-counting frenzies around the place =) I wonder if, ABI-wise, we could static link sal with libmerged for the purpose of LTO and get away with it =) Since there is no real C++ ABI, and no exported symbols, particuarly exceptions there - that could work across platforms and give a big win. Ideally we could get down the chain from the grey (cf. attached picture) to the bottom there: cppuhelper, xmlreader, cppu, salhelper, sal. I imagine on Linux that would cause severe grief around exceptions - but I think Windows can handle that with string comparisons at some cost (?) I wonder if (assuming we still believe that C++ UNO plugins exists as a 'thing' ;-) We could try on Linux increasing libmerged to include all of the lower base code - too - and (perhaps) - symlink it to all of the old library names. I -think- (worth checking) that the library loader will resolve those through the symlink to the same library loaded once - arguably giving back-compatibility at the expense of some packaging changes (I guess). Might be worth playing with that; then again - if there are no benefits ;-) ... sounds like a good experiment to make though. ATB, Michael. -- michael.meeks@xxxxxxxxxxxxx <><, GM Collabora Productivity Hangout: mejmeeks@xxxxxxxxx, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe
Attachment:
lo.png
Description: PNG image
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
