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
next prev parent 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