On Thu 3. Oct 2019 at 9.12, Philip Guenther <guent...@openbsd.org> wrote:

> CVSROOT:        /cvs
> Module name:    src
> Changes by:     guent...@cvs.openbsd.org        2019/10/03 00:10:54
>
> Modified files:
>         libexec/ld.so  : dlfcn.c library_subr.c loader.c resolve.c
>                          resolve.h
>
> Log message:
> Use a better algorithm for calculating the grpsym library order.
> The existing code did a full recursive walk for O(horrible).  Instead,
> keep a single list of nodes plus the index of the first node whose
> children haven't been scanned; lookup until that index catches the
> end, appending the unscanned children of the node at the index.  This
> also makes the grpsym list order match that calculated by FreeBSD and
> glibc in dependency trees with inconsistent ordering of dependent libs.
>
> To make this easier and more cache friendly, convert grpsym_list
> to a vector: the size is bounded by the number of objects currently
> loaded.
>
> Other, related fixes:
> * increment the grpsym generation number _after_ pushing the loading
> object onto its grpsym list, to avoid double counting it
> * increment the grpsym generation number when building the grpsym list
> for an already loaded object that's being dlopen()ed, to avoid
> incomplete grpsym lists
> * use a more accurate test of whether an object already has a grpsym list
>
> Prompted by a diff from Nathanael Rensen (nathanael (at)
> list.polymorpheus.com)
> that pointed to _dl_cache_grpsym_list() as a performance bottleneck.
>
> Much proding from robert@, sthen@, aja@, jca@
> no problem reports after being in snaps
> ok mpi@
>

Hi,

out of curiosity, do you have any numbers to share?

Thanks in advance,
Ville

Reply via email to