Re: [PATCH] Fix return code in _bfd_dwarf2_find_nearest_line().

["Steinar H. Gunderson" <sesse@google.com>]

On Tue, Mar 22, 2022 at 03:33:40PM +0000, Nick Clifton wrote:
> Patch approved and applied.  Thanks for fixing this!

Thanks for applying!

I have a related question about this fallback. In Chromium, scanning
through all the symbols one by one is a linked list of 975k elements
(which means chasing 975k pointers, with associated cache misses!).
With this patch, we hit that path a _lot_ less, but it's still about
half the CPU time of running perf for my use case (perhaps a bit less,
like 40%).

I looked into trying to making a faster structure, probably reusing the
trie from the other patch I posted (ie., making a separate trie that
maps address-to-symbol instead addition-to-compilation-unit), but it
seems the API is that the client has to send in the list of symbols it
wants to use for fallback? Is that right; so we cannot really create a
persistent structure? (The find_nearest_line function is marked as not
documented yet, so it's not all that easy to know what the intended API
is :-) )

/* Steinar */