Re: Small ld.elf_so speed up

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Apr 01, 2010 at 05:45:51PM +0100, Sad Clouds wrote:
> So, if you have an application that is linked to a total of 10 shared
> libraries. Each of those libraries exports 50 symbols. The application
> references all of those symbols, that is 10 * 50 = 500 symbols. This
> then increases load time.

No. It doesn't matter how many symbols a library *exports*. The question
is, how many relocations have to be resolved. That is, how many
undefined symbols are present. There is one exception here in that
global symbols in the same DSO may take some short cuts if they are not
exported, but that is not relevant for runtime linker overhead.

[snip]
> I don't know how dynamic linker is implemented, but I've been
> developing some of my packages/libraries as described above. I also
> added calls to pthread_mutex_lock() to make package init() and
> destroy() functions thread-safe.

You have essentially reimplemented what the dynamic linker does. Just in
a more expensive way. It is more expensive in terms of per-call overhead
as indirect calls can on most CPUs be considered as mispredicted branch.
It has larger startup overhead, because the relocations can't be done
lazy.

Joerg