From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dd17628.kasserver.com (dd17628.kasserver.com [85.13.138.83]) by sourceware.org (Postfix) with ESMTPS id 1E14B386F002 for ; Mon, 22 Jun 2020 08:29:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1E14B386F002 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=milianw.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mail@milianw.de Received: from milian-workstation.localnet (p54a1b1fb.dip0.t-ipconnect.de [84.161.177.251]) by dd17628.kasserver.com (Postfix) with ESMTPSA id 384AB628006E; Mon, 22 Jun 2020 10:29:34 +0200 (CEST) From: Milian Wolff To: "elfutils-devel@sourceware.org" , Josh Stone Subject: Re: Can dwarf_getscopes{,_die} performance be improved? Date: Mon, 22 Jun 2020 10:29:04 +0200 Message-ID: <10836829.MqxZEvEtCQ@milian-workstation> In-Reply-To: <786cfb66-db57-5a1f-1201-ff661f905bb0@redhat.com> References: <2050295.fxRyV3M0rs@milian-workstation> <786cfb66-db57-5a1f-1201-ff661f905bb0@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3886269.a7p2V0Nrlx"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 08:29:38 -0000 --nextPart3886269.a7p2V0Nrlx Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 --nextPart3886269.a7p2V0Nrlx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEezawi1aUvUGg3A1+8zYW/HGdOX8FAl7wa9AACgkQ8zYW/HGd OX+s5Q/8D+yc2gRykaTuKFJyXGiSlucAe5xRpv5l/+Mye8VBNS2/N9D9a2xNG0Ow bJ9FrIsGecl0jLIBu2E0ZhnkC1JdQ9JzibAsGkgKtysa+nsA2TyRmrgdtQ75Durf o6rIPWrBGgFM0PTRSDrj/I6oLWGhtLdpIjWLfvlK0n2mSAbsVwVJftsMzJOqusZs e91KIDHH9TR3c5U1N1RrX6fzKUsvbmFpNVncKXQJaAkvmUphwuHcEN/VO1lqyiJ8 EFpIZMRvNQFgv8akX/0A998NmdLL+X6GAPnkg8OxQOy7RA1P6K09K/AlD1YSQm3y 2vPUfiAbwcbQSmreBG4nEzzx2rmU0bpsVlciCpFb7ABzBkAVSiNuCqCePBVtMCv+ FwQotBgxwrkWgXom2sLb3eWctD8cM722uTdFxGrjUd/V3wk3qVLN3fXdVNDOK6FF 3cd49OTB7kMBMsP2rH7s5QW4qvm+ASBmNjn5KFkV5MmcaAvRIodbQeb7tERmJ0u5 uIuCNMWD71gLT00lqn0CYL7AP2IPByVvlZVA0au50aU20kmZGykEijpMvcUh7Ynz AgrNRdFTrlemCOdpJS8WOoJP3e+dj5yehDiU1zk8L9uOFxnZJrz8G61+JCeUTNTq yovBSrMszS0bKMSVOyVTciBn6wxOjH52FpYEY0KESsg23UuhwAo= =CQTY -----END PGP SIGNATURE----- --nextPart3886269.a7p2V0Nrlx--