Bug 3321 - ld slow linking large C++ shared library
Summary: ld slow linking large C++ shared library
Status: RESOLVED DUPLICATE of bug 3111
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-08 23:37 UTC by Scott L. Burson
Modified: 2006-10-16 21:49 UTC (History)
1 user (show)

See Also:
Host: x86_64-linux
Target: x86_64-linux
Build: x86_64-linux
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 ***