gprof is very slow (>100x worse than "before")

[Kevin Nomura <nomura at netapp dot com>]

This applies to at least gprof from binutils-2.11.  Is anyone
else noticing this, is it being addressed?  Here is some
analysis based on x86 a.out target, but I think it applies
to all targets.

corefile.c:core_create_line_syms has the following loop:

  for (offset = 0; offset < core_text_sect->_raw_size; offset += min_insn_size)
    {
      sym_init (ltab.limit);
      
      if (!get_src_info (core_text_sect->vma + offset, &filename,
			 &ltab.limit->name, &ltab.limit->line_num)
	  || (prev && prev->line_num == ltab.limit->line_num
	      && strcmp (prev->name, ltab.limit->name) == 0
	      && strcmp (prev->file->name, filename) == 0))
	continue;
       ...

As I read this, gprof initialization queries bfd for nearest-line 
info for every single byte of the text segment.  The nearest-line
query is expensive.  Doing anything for each byte of the text
segment is expensive.  The product of the two means, for example,
that gprof with default options took 100 minutes on a binary with
7.5MB text segment.  As a baseline, an old non-BFD-based gprof
takes a few tens of seconds.  Where it really hurts is when I try
to get source line granularity (--line option) -- it ran for 
48 hours without completing, before I cancelled it.

I coded a workaround which was to precompute a mapping from address
to source line, and hook get_src_info to binary-search this mapping.
Then "gprof --line" takes less than 5 minutes.  This is still doing
a lookup for each byte of the binary as above, so it seems that
the generic BFD routine is far too expensive for the brute-force
loop.  Certainly core_create_line_syms can be smarter too.  But
I don't know the rules of the game with BFD -- what symbol info
is exported, what new interfaces are reasonable to add -- these
rules might steer the fix in a certain direction.