From: Andrew Cagney <ac131313@redhat.com>
To: Elena Zannoni <ezannoni@redhat.com>,
Daniel Jacobowitz <drow@mvista.com>,
David Carlton <carlton@math.stanford.edu>
Cc: gdb <gdb@sources.redhat.com>, Jim Blandy <jimb@redhat.com>
Subject: Re: DW_AT_specification and partial symtabs
Date: Fri, 13 Jun 2003 15:38:00 -0000 [thread overview]
Message-ID: <3EE9EFFE.6050607@redhat.com> (raw)
In-Reply-To: <16105.55964.91811.625007@localhost.redhat.com>
Daniel wrote:
> > 1) is very easy to measure. GDB has a command line option --readnow
> > which forces symtabs to be read in immediately. I tried my normal
> > performance testcase: a dummy main() linked to all of mozilla's
> > component libraries, with full stabs debug info. Note stabs, not
> > DWARF2, so the timing may vary. Also note that we duplicate psymtab
> > and symtab creation doing it this way, so it overestimates the cost.
I think that's an understatement.
Elena wrote:
> But with --readnow we do both psymtabs and symtabs. I wonder, if we
> didn't do psymtabs at all, the time would improve, one hopes.
> And the memory footprint would shrink too.
Some back of envelope caculations are in order.
``(gdb) print sizeof (struct ...) indicates that sizeof(symtab) ~=
2*sizeof(psymtab) so GDB is burning 33% of allocated memory. Assuming
memory and file I/O are the bottle neck, slashing 33% of memory should
slash 33% of the time.
I just hope GDB isn't doing something stupid like searching psymtab
before symtab.
> > Note that none of those times is really acceptably fast, IMHO. Probably
> > they all can be improved. Looking at profiling data I see about three
> > seconds we can knock off the symbol reader and there are almost
> > certainly more.
I think oprofile data would be far more useful - remember the thread
problem where the profile data (and its suggested micro-optimizations)
were totally bogus. But having said that, wasn't there a proposal to
fix/rewrite BFD's mmap interface?
I think what's needed is a proper comparison of the current contents of
the symbol tabe VS exactly what and how often GDB requests that info.
For dwarf2, for instance, it now reads in all the location expression
stuff, and that, relatively speaking, is never used.
If psymtab's are dumped (or at least burried) the core GDB <-> symtab
interface is simplified/tightened, people can change the internals
without breaking everything. David, I belive, has been working in that
direction.
Andrew
next prev parent reply other threads:[~2003-06-13 15:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-12 17:01 David Carlton
2003-06-12 17:05 ` Daniel Jacobowitz
2003-06-12 17:10 ` David Carlton
2003-06-12 17:20 ` Elena Zannoni
2003-06-12 22:17 ` David Carlton
2003-06-13 13:36 ` Daniel Jacobowitz
2003-06-13 14:00 ` Elena Zannoni
2003-06-13 15:38 ` Andrew Cagney [this message]
2003-06-13 15:50 ` Daniel Jacobowitz
2003-06-13 15:57 ` Andrew Cagney
2003-06-13 16:24 ` Andrew Cagney
2003-06-13 16:34 ` Daniel Jacobowitz
2003-06-17 0:09 ` David Carlton
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=3EE9EFFE.6050607@redhat.com \
--to=ac131313@redhat.com \
--cc=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=ezannoni@redhat.com \
--cc=gdb@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