From: Daniel Berlin <dan@cgsoftware.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Jason Molenda <jason-swarelist@molenda.com>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method
Date: Sat, 15 Sep 2001 13:52:00 -0000 [thread overview]
Message-ID: <7370175E-AA1B-11D5-94ED-0030657B5340@cgsoftware.com> (raw)
In-Reply-To: <C854422C-AA18-11D5-94ED-0030657B5340@cgsoftware.com>
Since you seem to be having trouble either reading, or understanding,
what I have proposed, and implemented, let me break it down for you, in
simple english, so there is no confusion as to what you *think* i am
proposing (based on god knows what, probably some old email with a patch
from gdb-patches), and what I have proposed, and implemented:
First, you can speed up lookup_block_symbol. I sent you a patch hours
ago that does this.
It turns the linear array of symbols in a block into buckets of a
chained hashtable, adding a "hash_next" member to struct symbol to chain
them together.
The hash function is msymbol_hash_iw.
The hashed key is SYMBOL_SOURCE_NAME.
This turns block lookups, on non-function argument lists (function
argument lists aren't sorted, they have to be kept in the original
order), into O(1).
This makes your max symbol lookup time, O (j), where j is the number of
globally unique blocks.
Second, you can take lookup_symbol, and modify it to only call
lookup_block_symbol once.
This is done by providing a mapping from names to blocks they exist in,
using a hash table with SYMBOL_SOURCE_NAME keys, and sparse bitmaps as
the data, with a bit set per block it exists in.
Now, for undefined symbols, the cost is O(1), total. It won't exist in
the mapping, and thus, we know the symbol exists nowhere in the blocks.
For defined symbols, the cost is O(number of scopes to search), where
number of scopes to search <= all the blocks in the program, worst case
(in reality, it's usually < 20).
We simply test one bit per scope (since each scope is represented by a
single block), and as soon as we get a hit, we call lookup_block_symbol.
This will be O (number of scopes to search).
It will only call lookup_block_symbol *one* time.
Theoretically, number of scopes to search can be J, but this would
require every scope in your program be visible at once, which, unless
i'm mistaken, is pretty much impossible.
number of scopes to search is usually between 7 and 30, and is only
dependent on the nesting structure of your program, not it's size.
Now will you stop mischaracterizing what I have proposed?
It's pretty hard to do better than the above, but possible.
It would require a significant rework of the symbol table structure,
while both of the things above required a few hours each (In fact, I
redid the first one this morning, since I didn't have the source tree
around anymore).
next prev parent reply other threads:[~2001-09-15 13:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-09 7:48 Jason Molenda
2001-09-10 11:24 ` Michael Snyder
2001-09-10 11:32 ` Jason Molenda
2001-09-10 11:50 ` Daniel Berlin
2001-09-10 11:52 ` Daniel Berlin
[not found] ` <20010910130347.A5628@shell17.ba.best.com>
2001-09-10 14:17 ` Daniel Berlin
2001-09-14 7:53 ` Andrew Cagney
2001-09-14 8:53 ` Daniel Berlin
2001-09-14 9:06 ` Eli Zaretskii
2001-09-14 9:13 ` Jason Molenda
2001-09-14 9:58 ` Daniel Berlin
2001-09-14 10:55 ` Eli Zaretskii
2001-09-14 10:52 ` Eli Zaretskii
2001-09-14 10:59 ` Daniel Jacobowitz
2001-09-14 11:57 ` Eli Zaretskii
2001-09-15 0:54 ` Jason Molenda
2001-09-15 3:43 ` Eli Zaretskii
2001-09-15 8:01 ` Daniel Berlin
2001-09-15 9:09 ` Eli Zaretskii
2001-09-15 12:36 ` Daniel Jacobowitz
2001-09-15 12:52 ` Jason Molenda
2001-09-15 7:54 ` Daniel Berlin
2001-09-15 13:08 ` Jason Molenda
2001-09-15 13:33 ` Daniel Berlin
2001-09-15 13:52 ` Daniel Berlin [this message]
2001-09-15 14:02 ` Jason Molenda
2001-09-15 14:21 ` Daniel Berlin
2001-09-16 0:15 ` Eli Zaretskii
2001-09-17 22:56 ` Andrew Cagney
2001-09-17 23:12 ` Jason Molenda
2001-09-18 6:21 ` Daniel Berlin
2001-09-18 7:32 ` Andrew Cagney
2001-09-17 23:18 ` Daniel Jacobowitz
2001-09-18 4:51 ` Eli Zaretskii
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=7370175E-AA1B-11D5-94ED-0030657B5340@cgsoftware.com \
--to=dan@cgsoftware.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jason-swarelist@molenda.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