Another linker performance issue

[Pascal Obry]

John,

Thanks for your reply.

> Even if there is no progress in choosing a better global strategy
> for finding alias matches, the programmer can help the compiler generate
> better code.  20% better is only 20%, but that's one minute
> in this case.

Sadly not 20% :( I've tested with your patch and the performance
increase is only 3% that is we gain 1s (from 36.9s to 35.9s) in my small
test.

> [Does the original code have a bug when it checks
> (h->root.string[sl] == '@') even if (*hs == '@') ?
> The index [sl] looks suspicious in that case.]

I've been wondering the same. Look wrong to me too.

For the record I have attached a python file to generate sources to
reproduce the problem, on Windows do:

   $ mkdir src
   $ cd src
   $ python gen.py
   $ gcc -c *.c
   $ gcc -shared -o dll.dll file*.o

Note that the above command will be very slow if not using latest
version of the binutils (after Feb 11th).

Then do:

   $ time gcc -shared -o dll2.dll main.o -L. -ldll

This will takes ~ 10s with the generator above. Most of the time spent
in traversing the hash table:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 81.56      4.91     4.91   159205     0.00     0.00  bfd_link_hash_traverse
 15.03      5.82     0.91 120612797     0.00     0.00
pe_undef_alias_cdecl_matc
h_
  1.00      5.88     0.06   405741     0.00     0.00  bfd_hash_hash
  0.91      5.93     0.06   158802     0.00     0.00
pe_find_cdecl_alias_match
  0.33      5.95     0.02     2491     0.00     0.00  wild_sort

At this point I'm in a dead-end! Any idea?

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen.py
Type: text/x-python
Size: 393 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20120301/52455e71/attachment.py>