public inbox for binutils-cvs@sourceware.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@sourceware.org>
To: bfd-cvs@sourceware.org
Subject: [binutils-gdb] section-select: Fix performance problem (PR30367)
Date: Tue, 25 Apr 2023 12:58:35 +0000 (GMT)	[thread overview]
Message-ID: <20230425125835.B958F3858D1E@sourceware.org> (raw)

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

commit 8f5cd47bee6c07c33aeda758d8d8db5f81ae03e7
Author: Michael Matz <matz@suse.de>
Date:   Tue Apr 18 16:16:01 2023 +0200

    section-select: Fix performance problem (PR30367)
    
    when using many wild-statements with non-wildcard filenames we
    were running into quadraticness via repeatedly using lookup_name
    on a long list of loaded files.  I've originally retained using
    lookup_name because that preserved existing behaviour most obviously.
    In particular in matching wild-statements when using a non-wildcard
    filename it matches against local_sym_name, not the filename member.
    If the wildspec would have an archive-spec or a wildcard it would use
    the filename member, though.  Also it would load the named file
    (and ignore it, as being not equal to the currently considered
    input-statement).
    
    Rewrite this to not use lookup_name but retain the comparison
    against local_sym_name with a comment to that effect.
    
            PR 30367
            * ldlang.c (walk_wild_section_match): Don't use lookup_name
            but directly compare spec and local_sym_name.

Diff:
---
 ld/ldlang.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/ld/ldlang.c b/ld/ldlang.c
index 006031b5a65..9ad405aa06c 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -433,10 +433,18 @@ walk_wild_section_match (lang_wild_statement_type *ptr,
     }
   else
     {
-      lang_input_statement_type *f;
-      /* Perform the iteration over a single file.  */
-      f = lookup_name (file_spec);
-      if (f != file)
+      /* XXX Matching against non-wildcard filename in wild statements
+	 was done by going through lookup_name, which uses
+	 ->local_sym_name to compare against, not ->filename.  We retain
+	 this behaviour even though the above code paths use filename.
+	 It would be more logical to use it here as well, in which
+	 case the above wildcard() arm could be folded into this by using
+	 name_match.  This would also solve the worry of what to do
+	 about unset local_sym_name (in which case lookup_name simply adds
+	 the input file again).  */
+      const char *filename = file->local_sym_name;
+      if (filename == NULL
+	  || filename_cmp (filename, file_spec) != 0)
 	return;
     }

                 reply	other threads:[~2023-04-25 12:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20230425125835.B958F3858D1E@sourceware.org \
    --to=matz@sourceware.org \
    --cc=bfd-cvs@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).