From: Andrew Cagney <ac131313@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Elena Zannoni <ezannoni@redhat.com>,
David Carlton <carlton@math.stanford.edu>,
gdb <gdb@sources.redhat.com>, Jim Blandy <jimb@redhat.com>
Subject: Re: DW_AT_specification and partial symtabs
Date: Fri, 13 Jun 2003 16:24:00 -0000 [thread overview]
Message-ID: <3EE9FA99.8070201@redhat.com> (raw)
In-Reply-To: <20030613154932.GA313@nevyn.them.org>
> On Fri, Jun 13, 2003 at 11:38:38AM -0400, Andrew Cagney wrote:
>
>> 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.
>
>
> Not really. You can subtract the psymtab time from the combined time,
> and then compare. It still more than triples the time.
So we agree, 25% is significant but 3% is not.
A better question is what % of symtabs get draged in by a C++ `break
main; run'. Wasn't the original conjecture that symtabs get sucked in
anyway so why do it twice.
Remember, as we've discovered with threads, users define ``GDB is slow
to start'' differently to us as GDB developers. We think of it as:
$ gdb program
(gdb)
but the user appears to be more focused on things like:
(gdb) break main
and:
(gdb) run
Break point main reached
(gdb)
The first can be really badly fudged by not even loading the [p]symtab .
Just makes `break main' a bit slow :-)
So, we really don't know what symtab info is critical to GDB. An
uneducated guess, based on ``break main; run'' is:
- addr -> line
- function/symbol -> addr
- addr -> symbol
Andrew
next prev parent reply other threads:[~2003-06-13 16:24 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
2003-06-13 15:50 ` Daniel Jacobowitz
2003-06-13 15:57 ` Andrew Cagney
2003-06-13 16:24 ` Andrew Cagney [this message]
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=3EE9FA99.8070201@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).