public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: binutils@sources.redhat.com
Subject: Re: PATCH: Store ELF section index for input file
Date: Sun, 20 Mar 2005 13:38:00 -0000	[thread overview]
Message-ID: <20050320060831.GC29959@lucon.org> (raw)
In-Reply-To: <20050320054946.GN21148@bubble.modra.org>

On Sun, Mar 20, 2005 at 04:19:46PM +1030, Alan Modra wrote:
> On Sat, Mar 19, 2005 at 09:57:01AM -0800, H. J. Lu wrote:
> > On Sat, Mar 19, 2005 at 08:14:00PM +1030, Alan Modra wrote:
> > > On Thu, Mar 17, 2005 at 12:58:27PM -0800, H. J. Lu wrote:
> > > > @@ -4823,9 +4830,16 @@ _bfd_elf_section_from_bfd_section (bfd *
> > > >    const struct elf_backend_data *bed;
> > > >    int index;
> > > >  
> > > > -  if (elf_section_data (asect) != NULL
> > > > -      && elf_section_data (asect)->this_idx != 0)
> > > > -    return elf_section_data (asect)->this_idx;
> > > > +  if (elf_section_data (asect) != NULL)
> > > > +    {
> > > > +      index = elf_section_data (asect)->this_idx;
> > > > +      if (index != 0)
> > > > +	{
> > > > +	  Elf_Internal_Shdr **i_shdrp = elf_elfsections (abfd);
> > > > +	  if (!i_shdrp || i_shdrp [index]->bfd_section == asect)
> > > > +	    return index;
> > > > +	}
> > > > +    }
> > > 
> > > Please explain why this change is necessary.
> > > 
> > 
> > _bfd_elf_section_from_bfd_section is called on input sections. When
> > there are more than 64K input sections, linear search over a linked
> > list can be very very slow. Since this_idx isn't used for input section
> > and for input section, its bfd section is created from its ELF
> > section index, we can use this_idx to store the ELF section index. The
> > result is the linking time went from
> 
> No, I meant why that particular hunk.  You first posted a patch without
> it, then just said it was needed, but not why.
> 

I don't think it is really needed. I put it there for sanity check. I
think we can remove it.

> > 966.01s user 0.81s system 99% cpu 16:06.87 total
> > 
> > to
> > 
> > 45.61s user 0.81s system 99% cpu 46.448 total
> > 
> > It is 20X speed up. I tested it with Linux kernel, binutils, gcc and
> > glibc on ia32, ia64 and x86_64. There are no regressions.
> > 
> > BTW, it only solves the 64K input section problem. The 64K output
> > sections is still very slow. bfd_section has a pointer to its BFD
> > owner. Can we add a pointer to bfd_section, used_by_ld, which will
> > be used by ld for lang_output_section_statement_type?
> 
> I think it might be worth investigating a larger change, not creating
> lang_output_section_statemtents for orphans.  I'll look at this some
> time when I have a free moment or two.

Great.


H.J.

  reply	other threads:[~2005-03-20  6:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-17 22:03 RFC: " H. J. Lu
2005-03-17 23:06 ` PATCH: " H. J. Lu
2005-03-19 18:57   ` Alan Modra
2005-03-19 19:02     ` H. J. Lu
2005-03-20 13:22       ` Alan Modra
2005-03-20 13:38         ` H. J. Lu [this message]
2005-03-21  0:27           ` H. J. Lu
2005-03-21  2:07             ` Alan Modra

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=20050320060831.GC29959@lucon.org \
    --to=hjl@lucon.org \
    --cc=binutils@sources.redhat.com \
    /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).