public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>
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	[thread overview]
Message-ID: <bug-29303-9487@http.sourceware.org/bugzilla/> (raw)

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

            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=14184&action=edit
backtraces from several of the processes

The run time for doing self-compare's for a few packages is unacceptable. These
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-compare
-a --from fc36 dovecot
1196728 pts/3    R    787:03 python
/home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-compare
-a --from fc36 libdb
1259587 pts/3    R    884:13 python
/home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-compare
-a --from fc36 llvm11
1267329 pts/3    R    815:42 python
/home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-compare
-a --from fc36 lldb
1310898 pts/3    R    763:44 python
/home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-compare
-a --from fc36 mozjs91
1404655 pts/3    R    675:46 python
/home/ben/Shared/Work/test/libabigail-x86_64/bin//fedabipkgdiff --self-compare
-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 
#1  std::_Hashtable<abigail::ir::class_or_union const*,
abigail::ir::class_or_union const*, std::allocator<abigail::ir::class_or_union
const*>, std::__detail::_Identity, std::equal_to<abigail::ir::class_or_union
const*>, std::hash<abigail::ir::class_or_union const*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
true, true> >::_M_erase (__n=0x7fb1df831c60, __prev_n=0x7fb354000cf8,
__bkt=<optimized out>, this=0x7fb354000ce8) at
/usr/include/c++/12/bits/hashtable.h:2316
#2  std::_Hashtable<abigail::ir::class_or_union const*,
abigail::ir::class_or_union const*, std::allocator<abigail::ir::class_or_union
const*>, std::__detail::_Identity, std::equal_to<abigail::ir::class_or_union
const*>, std::hash<abigail::ir::class_or_union const*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
true, true> >::_M_erase(std::integral_constant<bool, true>,
abigail::ir::class_or_union const* const&) [clone .constprop.0] [clone .isra.0]
(this=0x7fb354000ce8, __k=@0x7fb3598b0460: 0x7fb31b0da190) at
/usr/include/c++/12/bits/hashtable.h:2370
#1  std::_Hashtable<abigail::ir::class_or_union const*,
abigail::ir::class_or_union const*, std::allocator<abigail::ir::class_or_union
const*>, std::__detail::_Identity, std::equal_to<abigail::ir::class_or_union
const*>, std::hash<abigail::ir::class_or_union const*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
true, true> >::_M_erase (__n=0x7fb1df831c60, __prev_n=0x7fb354000cf8,
__bkt=<optimized out>, this=0x7fb354000ce8) at
/usr/include/c++/12/bits/hashtable.h:2316
#2  std::_Hashtable<abigail::ir::class_or_union const*,
abigail::ir::class_or_union const*, std::allocator<abigail::ir::class_or_union
const*>, std::__detail::_Identity, std::equal_to<abigail::ir::class_or_union
const*>, std::hash<abigail::ir::class_or_union const*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
true, true> >::_M_erase(std::integral_constant<bool, true>,
abigail::ir::class_or_union const* const&) [clone .constprop.0] [clone .isra.0]
(this=0x7fb354000ce8, __k=@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.

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

             reply	other threads:[~2022-06-30  1:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30  1:07 woodard at redhat dot com [this message]
2022-06-30  1:07 ` [Bug default/29303] " woodard at redhat dot com
2022-06-30 12:44 ` dodji at redhat dot com
2022-06-30 12:54 ` dodji at redhat dot com
2022-07-05 23:15 ` woodard at redhat dot com
2022-07-07 13:58 ` woodard at redhat dot com
2022-07-12 15:55 ` dodji at redhat dot com
2022-07-12 15:56 ` dodji at redhat dot com
2022-07-28 23:44 ` woodard at redhat dot com
2023-04-06 11:21 ` dodji at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-29303-9487@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=libabigail@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).