[Patch, fortran, RFC] PR 40958 Reduce size of module files

[Janne Blomqvist]

On Mon, Nov 28, 2011 at 17:00, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> That said, I took a quick look through the appropriate bits of
> module.c to see what might be involved in not expanding module files
> to include other, USEd modules. I think that it could be quite a
> straight forward matter to do the same as the NAG compiler; ie. to add
> USE statements to the module files.  The information is available for
> each namespace in the use_stmts structure, so the write part should be
> relatively easy to do.  I ***THINK*** that the changes to module_read
> should be easy, since the effect should be exactly the same as if the
> USED modules had been read previously.  Thus, the main addition would
> have to be the utilisation of the USE statments stored in the module
> file.
>
> If the quoted ratio between gfortran and NAG module file sizes are
> typical, this would be a very high return exercise.

I suspect this is not worth doing. As I've mentioned before, the Go
developers claim that one major reason why go compilation is so fast
is that transitive dependencies are included (go stores the "module"
information in the .o file, but the principle is similar to Fortran
modules). See pages 9-10 on

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


Also, Joost pointed out that this might break the trick we use to
avoid recompilation cascades. We store a checksum in the module file,
and replace a module file only if the checksum is different when
recompiling. If one then uses makefiles which specify dependencies in
terms of mod files, this prevents unnecessary recompilation cascades,
making development on large code bases much faster.

Consider if we have a module A that uses module B which uses module C.
If C changes such that C.mod also changes, then if A.mod and B.mod
contain "USE" statements, then both A and B have to be recompiled as
well. However, in the current scheme where we include transitive
dependencies, if B.mod doesn't change (say, B used an ONLY clause to
only import things which didn't change due to the C changes), then the
recompilation cascade stops at B, and A doesn't need to be recompiled
(nor further modules using A, and so forth).


So yes, the current approach will inevitably use more disk space, but
in this case I think it's worth it. There are, however, plenty of
other opportunities for reducing disk space usage. My zlib patch being
a relatively simple approach, that can of course be combined with
other changes. For instance, we could store attributes and stuff only
where they differ from the default and where they makes sense. E.g. no
need to specify a module variable as UNKNOWN-INTENT since intent makes
sense only for procedure dummy arguments. And so on.

-- 
Janne Blomqvist