Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jean-Marc Saffroy <saffroy@gmail.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] gdb script performance
Date: Thu, 30 Nov 2006 13:57:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0611301419070.9872@erda.mds> (raw)
In-Reply-To: <20061130031323.GA25957@nevyn.them.org>

On Wed, 29 Nov 2006, Daniel Jacobowitz wrote:

> On Thu, Nov 30, 2006 at 01:33:02AM +0100, Jean-Marc Saffroy wrote:
>> It seems the patches I posted yesterday on the gdb list have gone
>> completely unnoticed, so I guess I should resend them here.
>
> This is the right list for patches.  However, please be patient - there
> is a chronic scarcity of reviewers, but we all do what we can.

Given your usual responsiveness on the lists, I thought my mail may have 
been filtered somehow. Thanks for bearing with me!

>> This is still unfinished (hooks for invalidating the caches are missing,
>> and I'm sure performance can still be enhanced significantly), but before
>> going further, I'd like to know how you feel about integrating such
>> changes.
>
> I'm glad to see some of this stuff sped up.  However, I'm hopeful that
> there's a better way to do it - shouldn't there be a more efficiently
> searchable data structure for whatever you're caching in the first
> place?
>
> Maybe there isn't; just thinking out loud.

I asked myself the same question, and hoped someone would have the answer 
here. ;-)

For the PC cache, I guess that just about any address can be passed, so I 
doubt there is much room for improvement (except maybe a cache with more 
than one entry, should it be useful in some cases, but now it's probably 
unneeded).

For the symbol cache, I think referencing all symbols in a global hash 
table could be a solution; actually I was surprised there was not one 
already. That's a more radical solution than my current patch, it could 
take a fair amount of memory, and also would take me much more time to 
implement, given that I'm still new to gdb internals. But I'd like this 
approach too, if it makes things cleaner and yields good performance.


-- 
saffroy@gmail.com


  reply	other threads:[~2006-11-30 13:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30  0:33 Jean-Marc Saffroy
2006-11-30  1:04 ` Jim Blandy
2006-11-30 13:19   ` Jean-Marc Saffroy
2006-11-30 21:54     ` Michael Snyder
2006-11-30  3:13 ` Daniel Jacobowitz
2006-11-30 13:57   ` Jean-Marc Saffroy [this message]
2006-12-05 21:02     ` Daniel Jacobowitz

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=Pine.LNX.4.64.0611301419070.9872@erda.mds \
    --to=saffroy@gmail.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.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