[Bug gas/26381] New: gas: speed of LTO LTRANS units

[mliska at suse dot cz]

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.