Bug 80440 - Slow compile when USEing modules
Summary: Slow compile when USEing modules
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 7.0
: P3 normal
Target Milestone: 7.0
Assignee: Paul Thomas
URL:
Keywords: compile-time-hog
Depends on:
Blocks:
 
Reported: 2017-04-15 21:48 UTC by Andrew Benson
Modified: 2017-04-22 12:01 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-04-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Benson 2017-04-15 21:48:16 UTC
Compile times for code that makes extensive USEs of modules seems to be very 
slow in some cases. I've been doing some investigation of the cause of this 
with the hope that I can maybe figure out some way to speed things up.

For example, I have a smallish file - 700 lines of code, which takes around 3 
minutes to compile with a recent build of gfortran. Profiling f951 with 
valgrind I find that 63% of that time is spent in find_symtree_for_symbol(), 
which (if I understand correctly) is searching for a node in the symtree that 
already references some symbol being imported from a module. 

find_symtree_for_symbol() gets called directly 245,658 times in compiling this 
source file (and calls itself recursively almost 19 billion times!).

find_symtree_for_symbol() is just stepping through a binary branching tree 
looking for a reference to a given symbol, but (again, if I understood 
correctly), it can't use the usual bbt search approach because the tree is not 
ordered by the symbol name, so the search is O(n) rather than O(log n). 

If I ignore my ignorance of why the ordered tree isn't used here and go ahead and search it using the symbol name (ignoring case which seems to differ between the symbol name and the name of the symtree node) then I certainly get a substantial speed-up (the file I mentioned now compiles in 40s), and nothing seems to break. I ran the gfortan test suite which shows two FAILs:

gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/graphite/pr68279.f90   -
O  (internal compiler error)
gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/graphite/pr68279.f90   -
O  (test for excess errors)

but those show up when I run the test suite without any change to module.c 
anyway.

The patch I used is:

diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 6d3860e..f28a7b7 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4286,22 +4286,25 @@ mio_symbol (gfc_symbol *sym)
 static gfc_symtree *
 find_symtree_for_symbol (gfc_symtree *st, gfc_symbol *sym)
 {
-  gfc_symtree *s = NULL;
-
-  if (st == NULL)
-    return s;
-
-  s = find_symtree_for_symbol (st->right, sym);
-  if (s != NULL)
-    return s;
-  s = find_symtree_for_symbol (st->left, sym);
-  if (s != NULL)
-    return s;
+  int c;
+  
+  while (st != NULL)
+    {
+      c = strcasecmp(sym->name, st->name);
+      if ( c == 0 )
+       {
+         if ( !check_unique_name (st->name))
+           {
+             return st;
+           } else {
+           return NULL;
+         }
+       }
 
-  if (st->n.sym == sym && !check_unique_name (st->name))
-    return st;
+      st = (c < 0) ? st->left : st->right;
+    }
 
-  return s;
+  return NULL;
 }
Comment 1 janus 2017-04-16 13:34:03 UTC
See also the discussion starting at:

https://gcc.gnu.org/ml/fortran/2017-04/msg00039.html

find_symtree_for_symbol was originally introduced in r121824 for PR 30554.
Comment 2 Paul Thomas 2017-04-17 18:22:34 UTC
Author: pault
Date: Mon Apr 17 18:22:03 2017
New Revision: 246952

URL: https://gcc.gnu.org/viewcvs?rev=246952&root=gcc&view=rev
Log:
2017-04-17  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/80440
	* module.c (find_symtree_for_symbol): Delete.
	(read_module): Remove the call to the above.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
Comment 3 janus 2017-04-22 11:21:46 UTC
I guess r246952 fully fixes the issue. Can we close this PR?
Comment 4 Paul Thomas 2017-04-22 12:01:52 UTC
Hi Janus,

Thanks for the reminder :-)

Fixed on trunk and closed.

Paul