This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
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.