bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/29081] objdump -S tends to be slow for thunderbird with se


From: cvs-commit at gcc dot gnu.org
Subject: [Bug binutils/29081] objdump -S tends to be slow for thunderbird with separate debug info
Date: Mon, 08 Aug 2022 11:52:38 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=29081

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Martin Liska <marxin@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e441b55e94c905c6ee4417be3e5d88021d9c5aa6

commit e441b55e94c905c6ee4417be3e5d88021d9c5aa6
Author: Martin Liska <mliska@suse.cz>
Date:   Wed Aug 3 11:28:10 2022 +0200

    add splay tree for info_ptr -> CU mapping

    While using perf top for MozillaThunderbird I noticed quite some slow
    dissably call with source code involved. E.g.

    time ./objdump --start-address=0x0000000004e0dcd0
--stop-address=0x0000000004e0df8b -l -d --no-show-raw-insn -S -C
/usr/lib64/thunderbird/libxul.so

    took 2.071s and I noticed quite some time is spent in
    find_abstract_instance:

        33.46%  objdump  objdump               [.] find_abstract_instance
        18.22%  objdump  objdump               [.] arange_add
        13.77%  objdump  objdump               [.] read_attribute_value
         4.82%  objdump  objdump               [.]
comp_unit_maybe_decode_line_info
         3.10%  objdump  libc.so.6             [.] __memset_avx2_unaligned_erms

    where linked list of CU is iterated when searing for where info_ptr
    belongs to:

             : 3452   for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
        0.00 :   4c61f7: mov    0x10(%rbx),%rax
        0.00 :   4c61fb: test   %rax,%rax
        0.00 :   4c61fe: je     4c6215 <find_abstract_instance+0x365>
             : 3453   if (info_ptr >= u->info_ptr_unit && info_ptr <
u->end_ptr)
        0.00 :   4c6200: cmp    0x60(%rax),%rdx
       83.20 :   4c6204: jb     4c620c <find_abstract_instance+0x35c>
        0.00 :   4c6206: cmp    0x78(%rax),%rdx
        6.89 :   4c620a: jb     4c6270 <find_abstract_instance+0x3c0>
             : 3452   for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
        0.00 :   4c620c: mov    0x10(%rax),%rax
        7.90 :   4c6210: test   %rax,%rax
        0.00 :   4c6213: jne    4c6200 <find_abstract_instance+0x350>

    The following scan can be replaced with search in a splay tree and with
    that I can get to 1.5s and there are other symbols where the difference
    is even bigger.

    bfd/ChangeLog:

            PR 29081
            * dwarf2.c (struct addr_range): New.
            (addr_range_intersects): Likewise.
            (splay_tree_compare_addr_range): Likewise.
            (splay_tree_free_addr_range): Likewise.
            (struct dwarf2_debug_file): Add comp_unit_tree.
            (find_abstract_instance): Use the splay tree when searching
            for a info_ptr.
            (stash_comp_unit): Insert to the splay tree.
            (_bfd_dwarf2_cleanup_debug_info): Clean up the splay tree.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]