From: "Paul N. Hilfinger" <hilfingr@otisco.mckusick.com>
To: carlton@math.stanford.edu
Cc: gdb-patches@sources.redhat.com, aidan@velvet.net,
jimb@redhat.com, ezannoni@redhat.com
Subject: Re: [RFA] delete BLOCK_SHOULD_SORT
Date: Thu, 19 Sep 2002 01:04:00 -0000 [thread overview]
Message-ID: <200209190804.BAA27599@otisco.McKusick.COM> (raw)
In-Reply-To: <ro1u1knrlkj.fsf@jackfruit.Stanford.EDU> (message from David Carlton on 18 Sep 2002 15:15:40 -0700)
> I think the changes are pretty straightforward, though I'd appreciate
> it if somebody more conversant with ada-lang.c than I am could make
> sure I'm not missing anything with my change there.
David,
OK; let me explain what Ada is up to in the various places it does
symbol lookup, and you can decide if we (ahem) need a conversation on
this (vis-a-vis this thread or the other "dictionary" threads), or if
our needs introduce no new requirements.
The problem is that some of our symbol lookups essentially require searches for
regular expressions of the form
(.*__)?<NAME>(___.*)?
or for
<NAME>(___.*)?
Not much you can do about the former, of course, with the current
setup, except scan all symbols, and that's what we do. The second
pattern, however, can benefit for sorted blocks in an obvious way---
hence the ada-lang.c code you mentioned in an earlier message---but
doesn't need them. That is, we take advantage of BLOCK_SHOULD_SORT
when possible. I don't have measurements of the impact of not having
it. There are obvious ways to use caching when performance becomes a
problem (and we currently use them).
The other property of Ada is that when we have to search global or
all file-scope symbols, we generally want ALL matches to these patterns, or
ALL matches from a given block.
Paul Hilfinger
next prev parent reply other threads:[~2002-09-19 8:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-18 15:16 David Carlton
2002-09-18 19:25 ` Daniel Jacobowitz
2002-09-19 1:04 ` Paul N. Hilfinger [this message]
2002-09-19 6:29 ` Daniel Jacobowitz
2002-09-19 8:04 ` Andrew Cagney
2002-09-19 9:29 ` David Carlton
2002-09-22 16:02 ` Jim Blandy
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=200209190804.BAA27599@otisco.McKusick.COM \
--to=hilfingr@otisco.mckusick.com \
--cc=Hilfinger@otisco.mckusick.com \
--cc=aidan@velvet.net \
--cc=carlton@math.stanford.edu \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@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