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: DW_AT_specification and partial symtabs


On Fri, Jun 13, 2003 at 12:23:53PM -0400, Andrew Cagney wrote:
> >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.

I am pretty sure that the conjecture is false.  I've fixed several
things in this area.

I run GDB on target boards, over NFS root, with limited RAM, and full
debug info for libc and libstdc++.  When I mess up lazy loading, I
_notice_.  At least I'm not working on the 3MHz FPGA right now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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