LTO on Windows now working

[Michael Meeks]

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 at collabora.com <><, GM Collabora Productivity
Hangout: mejmeeks at gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lo.png
Type: image/png
Size: 421434 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20200925/aee53fd4/attachment-0001.png>