public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dhatch at ilm dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/15310] _dl_sort_fini is O(n^3) causing slow exit when many dsos
Date: Wed, 27 Mar 2013 20:33:00 -0000	[thread overview]
Message-ID: <bug-15310-131-Tr2hu2lrgt@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-15310-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=15310

--- Comment #3 from Don Hatch <dhatch at ilm dot com> 2013-03-27 20:33:23 UTC ---
(In reply to comment #2)
> Don,
> 
> I agree that the sorting could be made *far* faster.
> 
> Thanks for submitting this. We were well aware that the minimal fix for bug
> 13882 would cause some kind of performance regression, but it was a balance
> between a minimal fix and low risk of breakage. I reviewed the patch for 13882
> and even build a minimal framework for testing that dynamic loader function
> outside of the build.
> 
> Do you have the time to investigate this and propose a patch (requires
> copyright assignment)?

I do. I am working on a patch that resolves both this and bug 15311,
and I'll submit it here in a day or two.

I am very interested in what you came up with in the way of a unit
testing scheme for this function... I could certainly use it.
I've found it frustrating that the existing tests run by "make check"
(the ones I saw anyway)
involve just creating/compiling/running a handful of real programs...
to really stress test an implementation of _dl_sort_fini properly,
I'd want to (at least) enumerate all possible graphs
of up to 3 or 4 nodes, and call it on each of them,
which would be millions of examples...
and a few million randomly generated larger examples as well.
It's *really* easy to get this stuff wrong otherwise.

Also I'd like to start by moving the init sorting code into a function.
It looks to me like this code is duplicated in two places (dl-open.c
and dl-deps.c), and (after the fix for bug 15309)
it's identical in both places except that
one of them starts at i0=0 and the other starts at i0=1.
So this could be expressed cleanly as a new function _dl_sort_init that takes
i0
as a parameter.
Should I start by submitting a patch that does that,
with no functional change, and go from there?  Or should I let you
or someone else do this refactoring (possibly in conjunction
with making these sorting functions unit testable)?
Let me know how to proceed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


  parent reply	other threads:[~2013-03-27 20:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-27  7:47 [Bug dynamic-link/15310] New: " dhatch at ilm dot com
2013-03-27  8:12 ` [Bug dynamic-link/15310] " dhatch at ilm dot com
2013-03-27  8:45 ` dhatch at ilm dot com
2013-03-27 12:57 ` carlos at redhat dot com
2013-03-27 14:19 ` ppluzhnikov at google dot com
2013-03-27 20:33 ` dhatch at ilm dot com [this message]
2013-03-27 20:50 ` neleai at seznam dot cz
2013-03-27 20:50 ` [Bug dynamic-link/15310] New: " Ondřej Bílka
2013-03-27 21:00 ` [Bug dynamic-link/15310] " carlos at redhat dot com
2013-03-27 21:07 ` carlos at redhat dot com
2013-03-27 21:13 ` law at redhat dot com
2013-03-27 23:44 ` dhatch at ilm dot com
2013-03-28  0:31 ` dhatch at ilm dot com
2013-03-28  7:42   ` Ondřej Bílka
2013-03-28  7:42 ` neleai at seznam dot cz
2013-03-28 10:00 ` dhatch at ilm dot com
2013-03-28 10:19 ` dhatch at ilm dot com
2013-03-28 17:09 ` law at redhat dot com
2013-03-28 17:31 ` dhatch at ilm dot com
2013-04-02  9:54 ` dhatch at ilm dot com
2013-04-02 11:31   ` Ondřej Bílka
2013-04-02 11:31 ` neleai at seznam dot cz
2013-04-02 13:07 ` dhatch at ilm dot com
2013-04-02 23:37 ` dhatch at ilm dot com
2013-04-03  7:57   ` Ondřej Bílka
2013-04-03  7:57 ` neleai at seznam dot cz
2013-04-06 21:07 ` carlos at redhat dot com
2014-06-13 13:51 ` fweimer at redhat dot com
2014-06-13 18:37 ` fweimer at redhat dot com
2021-10-27 14:58 ` adhemerval.zanella at linaro dot org
2021-10-27 14:59 ` adhemerval.zanella at linaro dot org

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-15310-131-Tr2hu2lrgt@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@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).