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.