public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Cary Coutant <ccoutant@google.com>,
	GDB/Archer list <archer@sourceware.org>
Subject: Re: [RFC] Proposal for a new DWARF name index section
Date: Wed, 02 Dec 2009 16:11:00 -0000	[thread overview]
Message-ID: <20091202161049.GD4450@tintin.torimasen.com> (raw)
In-Reply-To: <m34ooapkwk.fsf@fleche.redhat.com>

On Tue, Dec 01, 2009 at 12:13:47PM (-0700), Tom Tromey wrote:
> The biggest fixable performance problem in the current reader is
> actually computing the hash codes for the strings from the
> .debug_gnu_index section.  So, I've been thinking about putting the hash
> code directly into the section.

FWIW, from a G++ pov, I think it'd be tempted to say "let's try to
implement this and see how much GDB gains" so that we can have data to make
an educated choice. So I'd be on the "yes, let's try side" of the story
here.

> 
> The other problem I've noticed is name canonicalization.  This past
> year, we changed gdb to canonicalize names in its symbol tables, and to
> canonicalize user input before doing lookups.  This lets gdb return the
> right answer even when the order of modifiers varies.  This change
> slowed down DWARF reading, and it occurred to me that it would also
> substantially slow down index reading.  So, I would also like to change
> the .debug_gnu_index spec to specify how names are to be canonicalized.

Just to be sure I understand. How saying _how_ the strings are to be
canonicalized is going to speed up significantly GDB's processing?
I would have have thought that the killer gain would come from the
producing directly what the consumer expects. I guess I am missing
something.

        Dodji

  parent reply	other threads:[~2009-12-02 16:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-10  9:04 Dodji Seketeli
2009-08-10 14:38 ` Jan Kratochvil
2009-08-10 17:36   ` Tom Tromey
2009-08-10 18:21     ` Jan Kratochvil
2009-08-11  7:55       ` Dodji Seketeli
2009-08-11 17:45         ` Jan Kratochvil
2009-08-11 22:43           ` Tom Tromey
2009-08-12 19:20             ` Jan Kratochvil
2009-08-11 22:29       ` Tom Tromey
2009-08-20 17:31 ` Dodji Seketeli
2009-11-17 23:46   ` Cary Coutant
2009-11-20 17:25     ` Tom Tromey
2009-11-22  4:39       ` Daniel Jacobowitz
2009-11-23 19:51         ` Tom Tromey
2009-12-01 19:14       ` Tom Tromey
2009-12-02  5:17         ` Daniel Jacobowitz
2009-12-02 17:07           ` Tom Tromey
2009-12-02 17:35             ` Daniel Jacobowitz
2009-12-02 19:23               ` Tom Tromey
2009-12-02 19:39                 ` Daniel Jacobowitz
2009-12-03  1:46                   ` Paul Pluzhnikov
2009-12-04 23:13                     ` Tom Tromey
2009-12-06  3:41                       ` Tom Tromey
2009-12-07 21:32                         ` Tom Tromey
2009-12-02 16:11         ` Dodji Seketeli [this message]
2009-12-02 17:29           ` Tom Tromey
2009-12-11 23:56     ` Tom Tromey
2009-12-12  0:06       ` Daniel Jacobowitz
2009-12-12  0:13       ` Cary Coutant
2009-12-13  3:48       ` Dodji Seketeli
2009-12-14 15:32       ` Dodji Seketeli

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=20091202161049.GD4450@tintin.torimasen.com \
    --to=dodji@redhat.com \
    --cc=archer@sourceware.org \
    --cc=ccoutant@google.com \
    --cc=tromey@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).