Re: Question re: dynamic linking in musl

[Szabolcs Nagy <nsz@port70.net>]

* Alex Dowad <alexinbeijing@gmail.com> [2015-05-27 13:18:42 +0200]:
> On 27/05/15 12:40, Alexander Monakov wrote:
> >That is not how ELF symbol lookup works.  Simply put, the symbol should be
> >taken from whatever first module in the whole lookup chain provides it; e.g.
> >if the executable exports a function that is also exported in libX11, the
> >executable's definition prevails.
> OK, I get it. So dynamic linking has O(n^2) runtime, with "n" being the
> number of dynamic libraries you link against!

yes, in the sense that a symbol lookup is O(n) and you may
have O(n) such lookups.

> >Recently I was working on some dynamic linker speedups for musl.  On my
> >testcase, Clang/LLVM with ~100-200 dynamic libraries and ~20000 symbols that
> >need to be resolved in the dynamic linker, I obtained a speedup from 240 ms to
> >110 ms, while glibc needs 50 ms with lazy binding and 140 without.  So while
> >musl's dynamic linker speed can be improved, still rrdtool is doing something
> >odd in the first place if it's performance is bound like that.  I'd like to
> >understand that.  If it's unavoidable, perhaps static linking is appropriate.
> >
> >(I didn't send my dynlink speedup patches yet;  I intend to do that sometime
> >soon)
> That speedup will be very welcome, especially for clang! clang builds are
> noticeably slower than gcc. Looking forward to it.
> 

may be clang should be linked staticly then
(if dynamic linker has meausrable overhead)

btw i recently heard that benchmarks show that
clang compiles very fast.. but only if it was
compiled with gcc.. the irony

...
> cob=(1) /lib/ld-musl-i386.so.1
> cfi=(47) /home/buildozer/aports/main/musl/src/musl-1.1.5/src/exit/atexit.c
...

i386 pic code is slow even if the musl loader
is magically fast so if you care about performance
then static linking is the right solution.