From: Andrew Benson <abenson@carnegiescience.edu>
To: Thomas Koenig <tkoenig@netcologne.de>
Cc: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: Optimization in load_generic_interfaces()
Date: Wed, 22 Aug 2018 17:48:00 -0000 [thread overview]
Message-ID: <21321593.pGr8XM0jkI@andrew-precision-3520> (raw)
In-Reply-To: <a42c5af8-9c04-9ddd-12f6-8f341d1f183d@netcologne.de>
Committed as r263784.
Thanks,
Andrew
On Wednesday, August 22, 2018 5:43:30 PM PDT Thomas Koenig wrote:
> Hi Andrew,
>
> [please also copy in gcc-patches for patches]
>
> > I'm continuing to look for optimizations to improve compile times for
> > files
> > which USE large numbers of modules containing large numbers of symbols.
> >
> > When the number of symbols becomes very large, find_symbol() becomes a
> > slow- point, because it can't use the structure of the balanced binary
> > tree to rapidly search the symtree, so just has to go through the whole
> > tree until it finds (or doesn't find) the symbol.
> >
> > I don't see a simple way to improve the speed of this function, but there
> > seems to be a simple change in load_generic_interfaces() which gives
> > significant speed up:
> >
> > Index: gcc/fortran/module.c
> > ===================================================================
> > --- gcc/fortran/module.c (revision 263667)
> > +++ gcc/fortran/module.c (working copy)
> > @@ -4559,9 +4559,6 @@ load_generic_interfaces (void)
> >
> > /* Decide if we need to load this one or not. */
> > p = find_use_name_n (name, &i, false);
> >
> > - st = find_symbol (gfc_current_ns->sym_root,
> > - name, module_name, 1);
> > -
> >
> > if (!p || gfc_find_symbol (p, NULL, 0, &sym))
> >
> > {
> >
> > /* Skip the specific names for these cases. */
> >
> > @@ -4570,6 +4567,9 @@ load_generic_interfaces (void)
> >
> > continue;
> >
> > }
> >
> > + st = find_symbol (gfc_current_ns->sym_root,
> > + name, module_name, 1);
> > +
> >
> > /* If the symbol exists already and is being USEd without being
> >
> > in an ONLY clause, do not load a new symtree(11.3.2). */
> >
> > if (!only_flag && st)
> >
> > This just delays the call to find_symbol() until after the first test of
> > whether the symbol needs to be loaded - if that test fails then
> > find_symbol() is never called.
> >
> > This has no significant effect on compile time for files which import
> > small
> > numbers of symbols. But for cases where the number is large I find that
> > the
> > compile time can be reduced by up to 40% in the cases I've tried.
> >
> > The change passes all regression tests cleanly.
>
> The patch is OK for trunk.
>
> Thanks!
>
> Regards
>
> Thomas
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://bitbucket.org/abensonca/galacticus
prev parent reply other threads:[~2018-08-22 17:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-20 22:31 Andrew Benson
2018-08-22 15:43 ` Thomas Koenig
2018-08-22 17:00 ` Andrew Benson
2018-08-22 17:43 ` Andrew Benson
2018-08-22 17:48 ` Andrew Benson [this message]
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=21321593.pGr8XM0jkI@andrew-precision-3520 \
--to=abenson@carnegiescience.edu \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=tkoenig@netcologne.de \
/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).