Bug 3321

Summary: ld slow linking large C++ shared library
Product: binutils Reporter: Scott L. Burson <Scott>
Component: ldAssignee: unassigned
Status: RESOLVED DUPLICATE    
Severity: normal CC: bug-binutils
Priority: P2    
Version: 2.17   
Target Milestone: ---   
Host: x86_64-linux Target: x86_64-linux
Build: x86_64-linux Last reconfirmed:

Description Scott L. Burson 2006-10-08 23:37:16 UTC
Hi,

I have a large (~200MB) C++ shared library that links in a very reasonable 15
CPU sec. using older versions of ld (such as "2.15.92.0.2" from Red Hat
Enterprise 4, or "2.15.90.0.1.1" from SuSE Enterprise 9), but with "2.16.91.0.5"
from SuSE Enterprise 10 and also a stock 2.17, takes more than 10 CPU minutes.

The vast majority of the time is being spent on the following call chain:

elf_link_input_bfd (bfd/elflink.c: 7155)
_bfd_elf_check_kept_section (bfd/elflink.c: 6802)
match_group_member (bfd/elflink.c: 6778)
bfd_elf_match_symbols_in_sections (bfd/elf.c: 8629)
qsort and callees

I tried #if-ing out the statement in `elf_link_input_bfd' beginning with `if
(action & PRETEND)', and the link time is back down to ~25 CPU sec.  The comment
above that statement suggests that it may not be necessary with a recent GCC
anyway.  I built the whole application this way and it seems to work fine, so
this seems to be an adequate temporary workaround.

As far as a real fix, I'm thinking maybe to add a member `checked_kept_section'
to `struct bfd_section' that `_bfd_elf_check_kept_section' could cache its
result in.  Haven't tried this, though.
Comment 1 H.J. Lu 2006-10-16 21:49:42 UTC

*** This bug has been marked as a duplicate of 3111 ***