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


Hi Tor,

        Thanks for the nice summary :-)

On Thu, 2012-05-17 at 12:22 +0300, Tor Lillqvist wrote:
libraries into fewer. There is an option for that already,
--enable-mergelibs, that merges quite a large number of them into one,
libmergedlo.so. This works only for libraries in gbuildified modules,
built in tail_build.
...
Anyway, this indeed has helped a lot. But not enough. I am not sure if
the number of libraries merged this way can be easily increased much
at this stage of gbuildification.

        IIRC the gbuild-ification work is continuing apace, and my hope was
that the two davids, matus & others' work on the large number of
gbuild_* git branches would get merged - and unblock tail_build so that
it can incorporate many more of the libraries that are already
gnu-makeized which in turn would help us getting much more into
libmerged ...

        That at least is my hope: David ? what's the plan there :-) hopefully
that good stuff is all going in somewhat before the 3.6 feature-freeze ?

        Then again - the linking speedup from merging all that lot together has
an upper bound of ~7% CPU time in 3.5.4 (at least for me), though
there'd be potentially useful size savings, improved optimisations etc.

1) One way would be to identify libraries that are used only by one
other library, and then merge those. Unfortunately doing this
uncoditionally (on all platforms) encounters quite some stop energy.

        Hopefully not :-) if we can show that there is some pointless split, I
don't see why we can't merge things. Of course, there are a number of
existing divisions that are perhaps worthwhile / necessary to keep: URE
vs. non-URE, GUI & non-GUI, but beyond that - IMHO merging makes sense
[ though I'd be happier to see it done with static libraries, rather
than wholesale code movement perhaps ;-].

So it would have to be done conditionally just for Android 

        Clearly we want to share as much as possible with libmerged I guess,
and that work sounds generally useful.

2) Another way would be to start using another dynamic linker, namely
the one Mozilla uses on Android, known as "faulty.lib" for some
reason. See https://github.com/glandium/faulty.lib . It doesn't have
the silly limitation on the number of shared libraries.

Unfortunately, it brings in another problem: It doesn't handle text
relocations.

        How do Mozilla get away without any text relocations ? and/or - why are
we re-locating .text - it sounds profoundly crazy :-) surely that is
readonly. Is there a better toolchain to use ?

Of course, linking all required code into one shared object means that
this linking will take quite some time, especially if debugging
information has been included.

        Nasty indeed; unclear what we can do here, beyond profiling and/or
begging the linker guys :-) Of course, continuing to have a non-merged
option for rapid development where it is not necessary seems important
to me; and perhaps CPU's or L3 cache-sizes will save us in the end ;-)

        HTH,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot


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.