From: Doug Evans <xdje42@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patchv3 2/2] Accelerate lookup_symbol_aux_objfile 85x
Date: Tue, 02 Dec 2014 03:07:00 -0000 [thread overview]
Message-ID: <m3ppc2698r.fsf@sspiff.org> (raw)
In-Reply-To: <20141129121124.GA21606@host2.jankratochvil.net> (Jan Kratochvil's message of "Sat, 29 Nov 2014 13:11:24 +0100")
Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> On Fri, 24 Oct 2014 09:16:01 +0200, Doug Evans wrote:
>> This breaks an abstraction boundary, IWBN to preserve it.
>> [IOW, I look at dict_* as being an implementation detail of blocks.]
>>
>> If we were to go this route (and apologies for the delay), can you
>> write a routine like lookup_block_symbol which does the above and call
>> that here instead?
>>
>> lookup_block_symbol should live in block.c, not symtab.c.
>> That's where this new routine should go too.
>
> Done.
>
> For the 'slow.C' test the performance gain is even higher; but I have not
> re-benchmarked the 'non-trivial app':
> Command execution time: 26.540344 (cpu), 26.575254 (wall)
> ->
> Command execution time: 0.310607 (cpu), 0.311062 (wall)
> = 85x
>
> OK for check-in?
>
> No regressions on {x86_64,x86_64-m32,i686}-fedora21-linux-gnu native and in
> DWZ and in -fdebug-types-section modes.
>
>
> Thanks,
> Jan
> gdb/
> 2014-11-28 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> * block.c (block_lookup_symbol_primary): New function.
> * block.h (block_lookup_symbol_primary): New declaration.
> * symtab.c (lookup_symbol_in_objfile_symtabs): Assert BLOCK_INDEX.
> Call block_lookup_symbol_primary.
Hi.
I was reviewing all the callers of lookup_symbol_in_objfile_symtabs.
This patch assumes we're looping over all objfiles,
but some callers aren't. e.g., lookup_symbol_in_objfile_from_linkage_name.
It seems like we'll need to make a copy of lookup_symbol_in_objfile_symtabs
and call that in lookup_symbol_in_objfile (plus I'd add some comments
to lookup_symbol_in_objfile warning the reader that included symtabs
are not searched).
I could be missing something though.
next prev parent reply other threads:[~2014-12-02 3:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 21:44 [patch 0/2] Accelerate symbol lookups 15x Jan Kratochvil
2014-10-22 8:55 ` Doug Evans
2014-10-23 18:24 ` [patchv2 2/2] Accelerate lookup_symbol_aux_objfile 14.5x [Re: [patch 0/2] Accelerate symbol lookups 15x] Jan Kratochvil
2014-10-24 7:16 ` Doug Evans
2014-10-24 7:33 ` Jan Kratochvil
2014-10-24 16:07 ` Doug Evans
2014-10-27 5:55 ` Doug Evans
2014-10-27 6:02 ` Doug Evans
2014-10-27 8:54 ` Jan Kratochvil
2014-11-29 12:11 ` [patchv3 2/2] Accelerate lookup_symbol_aux_objfile 85x Jan Kratochvil
2014-12-02 3:07 ` Doug Evans [this message]
2014-12-03 18:05 ` Jan Kratochvil
2014-12-04 6:21 ` Doug Evans
2014-12-04 7:27 ` [commit] " Jan Kratochvil
2014-10-22 8:57 ` [patch 0/2] Accelerate symbol lookups 15x Doug Evans
2014-10-24 7:19 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ppc2698r.fsf@sspiff.org \
--to=xdje42@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).