* Bcache'ing as a speedup
@ 2000-04-13 8:19 Daniel Berlin
2000-04-26 14:51 ` Jim Blandy
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Berlin @ 2000-04-13 8:19 UTC (permalink / raw)
To: gdb
Ya know, i was thinking (yes, dangerous, i know).
If we bcache every symbol/psymbol/minsym name, and i mean literally
every single one, couldn't we just do simple pointer compares (IE
a==b) rather than strcmp (assuming we weren't doing a strcmp_Iw, which
obviously would still need to be done), since if they were the same
string, they would *have* to be pointing to the same memory?
Wouldn't this be a pretty large speed win?
--Dan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bcache'ing as a speedup
2000-04-13 8:19 Bcache'ing as a speedup Daniel Berlin
@ 2000-04-26 14:51 ` Jim Blandy
2000-04-26 16:00 ` Tom Tromey
0 siblings, 1 reply; 4+ messages in thread
From: Jim Blandy @ 2000-04-26 14:51 UTC (permalink / raw)
To: dan; +Cc: gdb
> If we bcache every symbol/psymbol/minsym name, and i mean literally
> every single one, couldn't we just do simple pointer compares (IE
> a==b) rather than strcmp (assuming we weren't doing a strcmp_Iw, which
> obviously would still need to be done), since if they were the same
> string, they would *have* to be pointing to the same memory?
>
> Wouldn't this be a pretty large speed win?
Have you actually observed that GDB spends a lot of time in strcmp, or
is that just a guess? You could be right, but guesses of that species
are notoriously poor bets.
Also: whenever you notice that a program spends a lot of time doing
procedure X, there are two approaches (not necessarily mutually
exclusive): you can make procedure X faster, or you can reduce the
number of times procedure X is needed.
For example, speeding up the minsym lookups with hash tables was a
localized change that was very effective. Rather than speeding up
strcmp, Tom introduced a better data structure, so that we only called
strcmp a tiny fraction as often as we used to.
The change you suggest has some pretty global consequences; for
example:
- symbol names can no longer be freed with their objfile
- everyone must always remember to bcache their names before looking
them up / storing them, or else lookups will mysteriously fail
I think there are bigger wins elsewhere, without these side effects.
Srikanth at HP has spent some time observing where GDB spends its time
in real-life situations, and has implemented some speedups in HP's
version of GDB that look attractive to me. For example, Srikanth
found that GDB could spend 40% of its symbol reading time trying to
demangle symbols, so he worked out some changes to GDB's minsym
structures that allow GDB to demangle C++ symbol names selectively, as
needed, rather than all at once when the symbol table is read. HP and
I have been talking about getting this change merged; we'll probably
be describing it on this list sometime soon.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bcache'ing as a speedup
2000-04-26 14:51 ` Jim Blandy
@ 2000-04-26 16:00 ` Tom Tromey
2001-09-05 0:12 ` Tom Tromey
0 siblings, 1 reply; 4+ messages in thread
From: Tom Tromey @ 2000-04-26 16:00 UTC (permalink / raw)
To: gdb
Jim> Have you actually observed that GDB spends a lot of time in
Jim> strcmp, or is that just a guess? You could be right, but guesses
Jim> of that species are notoriously poor bets.
For those who are interested in gdb profiling, long ago (October, I
think) I sent in a patch which adds the ability to control profiling
of gdb from the gdb command line. It was rejected, I think, but that
doesn't make it less useful.
Tom
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bcache'ing as a speedup
2000-04-26 16:00 ` Tom Tromey
@ 2001-09-05 0:12 ` Tom Tromey
0 siblings, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2001-09-05 0:12 UTC (permalink / raw)
To: gdb
Jim> Have you actually observed that GDB spends a lot of time in
Jim> strcmp, or is that just a guess? You could be right, but guesses
Jim> of that species are notoriously poor bets.
For those who are interested in gdb profiling, long ago (October, I
think) I sent in a patch which adds the ability to control profiling
of gdb from the gdb command line. It was rejected, I think, but that
doesn't make it less useful.
Tom
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-09-05 0:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-13 8:19 Bcache'ing as a speedup Daniel Berlin
2000-04-26 14:51 ` Jim Blandy
2000-04-26 16:00 ` Tom Tromey
2001-09-05 0:12 ` Tom Tromey
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).