This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Terminally slow (75 seconds) on some steps



On Sat, 16 Aug 2003, Daniel Jacobowitz wrote:

> On Sat, Aug 16, 2003 at 12:36:52PM -0400, Andrew Cagney wrote:
> >
> > >See SYMBOL_SET_NAMES - I fixed that fairly recently.  Also,
> > >add_psymbol_to_list is how most partial symbols are added; that uses
> > >the same name cache.  If you're talking about the call to bcache in
> > >add_psymbol_with_dem_name_to_list, it's only used by hpread.c.  Fixing
> > >this did in fact improve the hit rate.
> >
> > Ah.  So the only bcache call is to add the partial symbol to the psymbol
> > cache.  That narrows things down a bit.  Wonder if setting
> > CHAIN_LENGTH_THRESHOLD lower would help.
> >
> > >>>c011f6b8 663       2.3393     vmlinux                  do_anonymous_page
> > >>>00000000 622       2.1946     XFree86                  (no symbols)
> > >>>08134b74 574       2.0253     gdb                      read_partial_die
> > >
> > >>
> > >>Ok, so its spending a lot of time reading partial symbols.
> > >
> > >
> > >I've got some plans in this direction... just haven't had time to do
> > >anything about it yet :(
> >
> > What about the kernel?  3.5 seconds copying data to the user space is
> > suprising.  Can linux, given page sized read requests do it using page
> > swapping?
> >
> > The other question is where in GDB (?) the requests are comming from.  I
> > suspect target read, but it could be symbol file related.
>
> First of all, we should be using mmap to access symbol files, at least
> when there are no relocations.

Been there, done that, was told to do it in BFD.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]