Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@redhat.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: Elena Zannoni <ezannoni@redhat.com>,
	Daniel Jacobowitz <drow@false.org>,
	David Carlton <carlton@kealia.com>,
	gdb@sources.redhat.com
Subject: Re: Huge slowdown since 6.0
Date: Fri, 20 Feb 2004 17:45:00 -0000	[thread overview]
Message-ID: <16438.18096.205403.553354@localhost.redhat.com> (raw)
In-Reply-To: <40363D78.9080708@gnu.org>

Andrew Cagney writes:
 > > Daniel Jacobowitz writes:
 > >  > How can they possibly be to blame?  Well, they are.  And reverting the
 > >  > change for enumerators definitely won't do any harm.  Take a look at
 > >  > this, read it two or three times if necessary - it took me about a
 > >  > dozen:
 > >  > 
 > >  > > > -                          &objfile->static_psymbols,
 > >  > > > +                          cu_language == language_cplus
 > >  > > > +                          ? &objfile->static_psymbols
 > >  > > > +                          : &objfile->global_psymbols,
 > >  > 
 > >  > If I swap "static" and "global", it reduces GDB startup time by roughly
 > >  > 40% for glibc with debug information, which contains a lot of C
 > >  > enumerators.  I assume that is what you meant to do in the first place?
 > >  > If so I can recover the speed hit for C for GDB 6.1, and then address
 > >  > the larger issues with large numbers of global psymbols in HEAD after
 > >  > we branch.
 > > 
 > > Another point in favor of the theory that conditional expressions are
 > > bad.
 > > 
 > > This should be fine, consider it preapproved. However, what you are
 > > really saying is that qsort performance is really bad in case we have
 > > lots of symbols to sort. But how many symbols? You didn't post the
 > > numbers.
 > 
 > Hmm, begs a few questions:

sorry, I am talking about partial symbols. It's not clear from the above.

 > 
 > - why do we load the symbols during startup?
 > Load globals on demand?
 > - why do we sort the symbols during startup?
 > Use a hash (so that break main is fast) and sort when (break main<tab> 
 > is entered?)
 > - why don't we do more while GDB is twiddling its thumbs in the event 
 > loop event loop?

The thing that I am curious about is to see how early into a regular
debug session we build the symtabs. I.e. I am afraid that any
reference to any symbol from the command line makes the whole lot
expand anyway. The answer to this may help answer the question whether
we really need a two tier symbol table system, or if there is another
way of solving the same problem. While cleaning up the obstack stuff,
it became obvious that the intent was for the psymtabs to go away once
expanded into full symtabs, but this was never implemented.



  parent reply	other threads:[~2004-02-20 17:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-18 21:09 Daniel Jacobowitz
2004-02-18 21:31 ` David Carlton
2004-02-18 22:45   ` Kip Macy
2004-02-19  3:35     ` Daniel Jacobowitz
2004-02-19  5:06       ` Kip Macy
2004-02-19 15:40         ` Daniel Jacobowitz
2004-02-20  5:09   ` Daniel Jacobowitz
2004-02-20 16:42     ` Elena Zannoni
2004-02-20 16:47       ` Daniel Jacobowitz
2004-02-20 17:33         ` Elena Zannoni
2004-02-20 17:01       ` Andrew Cagney
2004-02-20 17:05         ` Daniel Jacobowitz
2004-02-20 17:45         ` Elena Zannoni [this message]
2004-02-20 18:07           ` Andrew Cagney
2004-02-20 18:24             ` Daniel Jacobowitz
2004-02-20 18:45               ` Andrew Cagney
2004-02-20 18:48                 ` Daniel Jacobowitz
2004-02-21  9:21                   ` Eli Zaretskii
2004-02-21  9:04                 ` Eli Zaretskii
2004-02-21  2:18           ` Daniel Jacobowitz
2004-02-20 16:52     ` David Carlton
2004-02-20 16:58       ` Daniel Jacobowitz
2004-02-20 17:00         ` David Carlton
2004-02-20 17:35       ` Elena Zannoni
2004-02-19  1:59 ` Elena Zannoni
2004-02-19  3:35   ` Daniel Jacobowitz
2004-02-19  3:58     ` Daniel Jacobowitz
2004-02-20 19:57 Michael Elizabeth Chastain
2004-02-23 19:22 ` Andrew Cagney

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=16438.18096.205403.553354@localhost.redhat.com \
    --to=ezannoni@redhat.com \
    --cc=cagney@gnu.org \
    --cc=carlton@kealia.com \
    --cc=drow@false.org \
    --cc=gdb@sources.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