From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AD18F38485AE; Thu, 30 Jun 2022 01:07:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD18F38485AE From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/29303] New: Unacceptable performance doing fedabipkgdiff on some packages Date: Thu, 30 Jun 2022 01:07:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: woodard at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2022 01:07:01 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29303 Bug ID: 29303 Summary: Unacceptable performance doing fedabipkgdiff on some packages Product: libabigail Version: unspecified Status: NEW Severity: normal Priority: P2 Component: default Assignee: dodji at redhat dot com Reporter: woodard at redhat dot com CC: libabigail at sourceware dot org Target Milestone: --- Created attachment 14184 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D14184&action=3Ded= it backtraces from several of the processes The run time for doing self-compare's for a few packages is unacceptable. T= hese were running for more than 11hrs. With the 2.0 version of libabigail their runtimes are more reasonable. 1125479 pts/3 R 819:36 python /home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-comp= are -a --from fc36 dovecot 1196728 pts/3 R 787:03 python /home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-comp= are -a --from fc36 libdb 1259587 pts/3 R 884:13 python /home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-comp= are -a --from fc36 llvm11 1267329 pts/3 R 815:42 python /home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-comp= are -a --from fc36 lldb 1310898 pts/3 R 763:44 python /home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-comp= are -a --from fc36 mozjs91 1404655 pts/3 R 675:46 python /home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-comp= are -a --from fc36 webkit2gtk3 Attached are backtraces from the running processes. These are hard to read and don't look immediately similar but one thing did jump out at me looking at them was: $ grep _M_erase backtraces.txt=20 #1 std::_Hashtable, std::__detail::_Identity, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_erase (__n=3D0x7fb1df831c60, __prev_n=3D0x7fb354000cf8, __bkt=3D, this=3D0x7fb354000ce8) at /usr/include/c++/12/bits/hashtable.h:2316 #2 std::_Hashtable, std::__detail::_Identity, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_erase(std::integral_constant, abigail::ir::class_or_union const* const&) [clone .constprop.0] [clone .isr= a.0] (this=3D0x7fb354000ce8, __k=3D@0x7fb3598b0460: 0x7fb31b0da190) at /usr/include/c++/12/bits/hashtable.h:2370 #1 std::_Hashtable, std::__detail::_Identity, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_erase (__n=3D0x7fb1df831c60, __prev_n=3D0x7fb354000cf8, __bkt=3D, this=3D0x7fb354000ce8) at /usr/include/c++/12/bits/hashtable.h:2316 #2 std::_Hashtable, std::__detail::_Identity, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_erase(std::integral_constant, abigail::ir::class_or_union const* const&) [clone .constprop.0] [clone .isr= a.0] (this=3D0x7fb354000ce8, __k=3D@0x7fb3598b0460: 0x7fb31b0da190) at /usr/include/c++/12/bits/hashtable.h:2370 4 out of 5 of them were in the process of some sort of hash table erase function. That seems suspicious to me. --=20 You are receiving this mail because: You are on the CC list for the bug.=