Can dwarf_getscopes{,_die} performance be improved?

[Milian Wolff]

On Montag, 15. Juni 2020 18:54:41 CEST Josh Stone wrote:
> On 6/13/20 10:40 AM, Milian Wolff wrote:
> > Has anyone an idea on how to to post-process the DWARF data to optimize
> > the
> > lookup of inlined frames?
> 
> SystemTap implements its own cache for repeated lookups -- see
> dwflpp::get_die_parents().

Thanks, I've come up with something similar over the weekend before reading 
your mail. The performance boost is huge (5x and more).

Looking at your code, I think that I'm not yet handling a few corner cases 
(such as imported units). That, paired with the fact that at least three users 
of this API have apparently by now come up with a similar solution clearly 
makes a case for upstreaming this into a common API.

As Mark wrote:

> It would probably make sense to build a parent DIE chain cache for a
> CU. The question is when/how we build the cache. There are also lots of
> programs that won't need it, or only for some, but not all CUs. It will
> take space and time to create.
> 
> The dwarf_getscopes[_die] calls might be a good trigger to create/keep
> them. And/or have some explicit way to create them, maybe triggered by
> some helper function to get at the parent of a DIE.

I believe that there is a lot of data that potentially needs to be cached. 
Additionally, doing it behind the scenes may raise questions regarding multi 
threaded usage of the API (see my other mail relating to that).

Which means: an explicit API to opt-in to this behavior is safest and best I 
believe. Maybe something as simple as the following would be sufficient?

```
/* Cache parent DIEs chain to speed up repeated dwarf_getscopes calls.

   Returns -1 for errors or 0 if the parent chain was cached already. */
extern int dwarf_cache_parent_dies(Dwarf_Die *cudie);
```

Alternatively a function that returns the cache could be considered, which 
would then require new versions of dwarf_getscopes* that take the cache as an 
argument.

Cheers
-- 
Milian Wolff
mail@milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/elfutils-devel/attachments/20200622/337045e5/attachment.sig>