https://sourceware.org/bugzilla/show_bug.cgi?id=19739
Bug ID: 19739 Summary: ld.bfd performance regression Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jan.sm...@alcatel-lucent.com Target Milestone: --- ld.bfd -r on mips When compiling object files with dwarf debug info the link time goes up significantly. I suspect this is due to the large amount of sections. I needed to reduce the amount of object files used in the example below because otherwise it would just never stop. Binutils 2.23.2, not very fast, but acceptable. Samples: 8K of event 'cycles', Event count (approx.): 5959804941 64.81% ld-new ld-new [.] _bfd_elf_make_section_from_shdr 11.45% ld-new [kernel.kallsyms] [k] 0xffffffff8103ba6a 2.51% ld-new ld-new [.] walk_wild_section_general 1.62% ld-new libc-2.12.so [.] __gconv_transform_utf8_internal Binutils 2.26 Samples: 214K of event 'cycles', Event count (approx.): 161542081964 68.51% ld-new ld-new [.] bfd_get_next_section_by_name 14.44% ld-new libc-2.12.so [.] __strcmp_sse42 10.75% ld-new ld-new [.] gldelf32btsmip_place_orphan 2.40% ld-new ld-new [.] _bfd_elf_make_section_from_shdr 1.67% ld-new [kernel.kallsyms] [k] 0xffffffff8103ba6a │ for (sh = (struct section_hash_entry *) sh->root.next; 0.00 │ test %rbx,%rbx │ ↓ je 50 │ sh != NULL; │ sh = (struct section_hash_entry *) sh->root.next) │ if (sh->root.hash == hash 0.78 │28: cmp %rbp,0x10(%rbx) 1.38 │ ↑ jne 20 │ && strcmp (sh->root.string, name) == 0) 85.90 │ mov 0x8(%rbx),%rdi 5.69 │ mov %r13,%rsi 0.01 │ → callq strcmp@plt │ hash = sh->root.hash; │ name = sec->name; Is this sufficient information ? Thanks -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils