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.