https://sourceware.org/bugzilla/show_bug.cgi?id=26381
Bug ID: 26381
Summary: gas: speed of LTO LTRANS units
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: mliska at suse dot cz
Target Milestone: ---
Created attachment 12767
--> https://sourceware.org/bugzilla/attachment.cgi?id=12767&action=edit
One ltrans of libxul.so (of 128)
I noticed that gas takes quite some time on Firefox LTRANS files:
$ time as /tmp/libxul-ltrans.s -o /dev/null
real 0m4.978s
user 0m4.761s
sys 0m0.214s
with the following perf profile:
46.95% as as [.] hash_lookup
5.37% as libc-2.31.so [.] __strncmp_avx2
5.24% as as [.] resolve_symbol_value
4.25% as as [.] do_scrub_chars
1.98% as libc-2.31.so [.] __strlen_avx2
1.89% as libz.so.1.2.11 [.] longest_match
After I applied the following fix:
https://sourceware.org/pipermail/binutils/2020-August/112831.html
I can get to:
$ time ./gas/as-new /tmp/libxul-ltrans.s -o /dev/null --hash-size=1000000
real 0m3.333s
user 0m3.192s
sys 0m0.139s
So one needs to use a bigger hash table. With that I get the following profile:
20.86% as-new as-new [.] hash_lookup
7.62% as-new as-new [.] resolve_symbol_value
6.89% as-new libc-2.31.so [.] __strncmp_avx2
5.63% as-new as-new [.] do_scrub_chars
3.04% as-new as-new [.] read_a_source_file
2.89% as-new as-new [.] get_symbol_name
2.83% as-new libc-2.31.so [.] __strlen_avx2
2.68% as-new as-new [.] longest_match
2.21% as-new as-new [.] check_eh_frame
So apparently, most of the time is spent in memory load of hash table entries
and their strcmp comparison. Can we do something about it in order to make it
faster?
Would it be possible to deduce hash tables sizes automatically (not using
--hash-size argument)?
--
You are receiving this mail because:
You are on the CC list for the bug.
