[Bug dynamic-link/24561] _dl_addr: linear lookup inefficient, making mtrace() feature very slow

["yann at droneaud dot fr" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=24561

--- Comment #7 from Yann Droneaud <yann at droneaud dot fr> ---
(In reply to Yann Droneaud from comment #6)
> 
> It could be possible to put every symbols in a dedicated data structure (per
> DSO, in link_map) on first call do dladdr().
> 
> At first glance, interval tree seems to be the solution for faster lookup.
> But I'm not going to invest time adding a dedicated tree implementation
> without any prior feedback.
> 
> Sorting the symbols by start address could be a first step, allowing the
> search to end as soon as next symbol is after the address being looked up.
> Note that binary search would not be possible in this partial optimisation.
> 

Building a sorted array (or a tree) from within _dl_addr() is likely going to
hurt as it would require memory allocations.

It's unfortunate _dl_addr() is used in mtrace.c's lock_and_info()[1] while
malloc()[2], realloc(), free(), etc. are hooked.

Calling malloc() would recursively call itsef ...

Putting the call to _dl_addr() after restoring the default malloc() could be
possible. But still quite brittle. And would hide the memory allocations made
by _dl_addr().

Also I don't think building the sorted array (or tree) on object loading is a
viable option: it would increase startup time, and use memory, for a feature
almost never used.

So I dunno.

[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/mtrace.c;h=2fda2625084270a1e75d8901ee8bd83f53d8806d;hb=cf274686024128f9fd75d4878211a018b2cfa5ac#l111
[2]
https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/mtrace.c;h=2fda2625084270a1e75d8901ee8bd83f53d8806d;hb=cf274686024128f9fd75d4878211a018b2cfa5ac#l185

-- 
You are receiving this mail because:
You are on the CC list for the bug.