[Bug fortran/25708] Module loading is not good at all

["jb at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jvdelisle at gcc dot        |pault at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #15 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-04-05 05:34:57 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > An associated issue is the size of module files.
> 
> Joost suggested to cut down the string tags "d" instead of "dimension", "al"
> instead of "allocatable" or something like that. That would help with the file
> size, the I/O (also: I/O caching), and the string parsing.

FWIW, this is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958

Another option would be to compress the mod file with zlib; there is a copy in
the gcc tree already.

There also seems to be a bit of redundancy in the module files, e.g. things
like null atoms "()" which I guess can be removed? I'm not sure how big an
effect this would have, though.

> > Clearly, where a module uses
> > another module, we could help by inserting use statements in the module file.
> 
> There are pro and cons doing so. For binary-only code, it is much more
> convenient to ship only a single ".mod" instead of several - that was at least
> a complaint I have heard about NAG's compiler. Though, having by default a
> simple "use" in the .mod file would help.

To reiterate my comments from 

http://gcc.gnu.org/ml/fortran/2010-09/msg00512.html 

the go developers claim that including the transitive dependencies is a major
reason why go compilation is fast. See pages 9-10 on 

http://assets.en.oreilly.com/1/event/45/Another%20Go%20at%20Language%20Design%20Presentation.pdf

In the Fortran case, additionally by doing it this way one can take care of
ONLY and renamed symbols when generating the .mod file.

> Another thing which could help is to read a .mod file only once per translation
> unit (source file) instead of every time a USE statement is encountered.

I think this is the major issue, yes.