This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/40958] New: module files too large


I notice that the module files gfortran generates are really large, and believe
that this could maybe be improved easily, which would reduce disk usage and
presumably improve compile time.

The observation is that a compilation of CP2K generates 130Mb of .mod files for
27Mb sources. Doing a 'cat *.mod > modall' and using that file for analysis, I
find that 'bzip2 modall' -> 6Mb file, so 20-fold compression. Compile time
seems to also have a large factor of system time which is presumably disk
access. With a single process on a fast RAID disk, I get the following time:

> gfortran -c -fsyntax-only -ftime-report CP2K_2009-05-01.f90

Execution times (seconds)
 garbage collection    :   8.20 ( 7%) usr   0.34 ( 1%) sys   9.33 ( 4%) wall   
   0 kB ( 0%) ggc
 callgraph construction:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 rebuild jump labels   :   1.13 ( 1%) usr   0.11 ( 0%) sys   1.32 ( 1%) wall   
   7 kB ( 0%) ggc
 parser                :  80.34 (64%) usr  27.25 (88%) sys 157.87 (74%) wall
1272352 kB (34%) ggc
 inline heuristics     :   4.58 ( 4%) usr   0.42 ( 1%) sys   5.63 ( 3%) wall   
  38 kB ( 0%) ggc
 tree gimplify         :   7.69 ( 6%) usr   0.71 ( 2%) sys   9.73 ( 5%) wall 
724206 kB (19%) ggc
 tree eh               :   0.27 ( 0%) usr   0.00 ( 0%) sys   0.42 ( 0%) wall   
   0 kB ( 0%) ggc
 tree CFG construction :   1.55 ( 1%) usr   0.18 ( 1%) sys   2.05 ( 1%) wall 
388675 kB (10%) ggc
 tree CFG cleanup      :   0.46 ( 0%) usr   0.03 ( 0%) sys   0.53 ( 0%) wall   
1901 kB ( 0%) ggc
 dominance computation :   0.25 ( 0%) usr   0.03 ( 0%) sys   0.42 ( 0%) wall   
   0 kB ( 0%) ggc
 expand                :  19.47 (16%) usr   1.82 ( 6%) sys  24.43 (11%) wall
1348665 kB (36%) ggc
 varconst              :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.06 ( 0%) wall   
 263 kB ( 0%) ggc
 final                 :   0.16 ( 0%) usr   0.02 ( 0%) sys   0.16 ( 0%) wall   
   0 kB ( 0%) ggc
 symout                :   0.03 ( 0%) usr   0.02 ( 0%) sys   0.05 ( 0%) wall   
  32 kB ( 0%) ggc
 TOTAL                 : 124.67            31.08           212.75           
3736334 kB

so a relatively large fraction of compile time is system time in the parser
(cpu usage during compilation is also rather far from 100%). Presumably a
parallel compile would be even more impacted.

While I don't have a good general solution, a nearly 50% improvement in mod
file size can be easily obtained by by-hand compression:

cat modall | sed "s/UNKNOWN/U/g" | sed "s/INTEGER/I/g" | sed "s/VARIABLE/V/g" |
 sed "s/PROCEDURE/P/g" | sed "s/DERIVED/D/g" | sed "s/CHARACTER/C/g" | sed
"s/SUBROUTINE/S/g" | sed "s/FUNCTION/F/g" | sed "s/ASSUMED_SHAPE/AS/g" | sed
"s/REAL/R/g" | sed "s/CONSTANT/CST/g" | sed "s/DIMENSION/M/g" | sed
"s/DUMMY/Y/g" | sed "s/LOGICAL/L/g" | sed "s/EXPLICIT/X/g" | sed "s/INTENT/T/g"
| sed "s/ACCESS/XS/g" | sed "s/POINTER/PT/g" | sed "s/DEFERRED/FR/g" >
modall.new

yields a 75Mb file (so roughly half of the original). Presumably that would
reduce the time needed to read the mod files by half, and might be faster to
parse. The down-side is that the module files are somewhat harder
human-readable, but that can't be their primary purpose. Looking at module.c,
such a change would be relatively easy to implement.


-- 
           Summary: module files too large
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]