[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gprof --line taking _forever_
From: |
Ian Lance Taylor |
Subject: |
Re: gprof --line taking _forever_ |
Date: |
14 Apr 2004 16:48:29 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
"David Mathog" <address@hidden> writes:
> > > However, when I try this:
> > >
> > > grpof --line /usr/common/ncbi_new/ncbi/build/blastall
> > >
> > > the CPU pegs at 99% and stays there for at least 45 minutes
> > > (it's still running as I write this.)
> >
> > You didn't mention which version of the binutils you are using. Also
> > relevant is type of debugging information--stabs or DWARF.
>
> Beats me, whatever version 3.3.3 of gcc emits by default with
> the command line options -g -pg on a RedHat 7.3 system.
You can tell by running objdump -h on the binary. If you see .stab
and .stabstr it is stabs. If you see .debug_info it is DWARF.
> > gprof --line is known to be slow. There have been various recent
> > efforts to speed it up by caching more information. The speedups have
> > been fairly dramatic in some cases. You may want to try a newer
> > version of the binutils to see if it helps.
>
> The old version was 2.11.93.0.2 and it ran somewhere between
> 70 and 80 minutes (I didn't time it exactly.) Following your
> advice I tried gprof 2.14 and used "time" on that one - it ran in
> 74m59s. So the newer version doesn't seem to be much (if any) better
> than the old one in terms of speed with --line. I also attempted
> to restrict gprof to the function where the most time was spent
> with:
>
> gprof --line --time=BlastWordFinder_mh_contig
>
> but that still ran in 74m19s.
Hmmm. Sorry for the wasted time.
I would appreciate it if you could file a PR at
http://sources.redhat.com/bugzilla/
Thanks.
Ian