From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-424856-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 13594 invoked by alias); 22 Jun 2013 19:45:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 13535 invoked by uid 48); 22 Jun 2013 19:45:34 -0000
From: "jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/40958] module files too large
Date: Sat, 22 Jun 2013 19:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jb at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-40958-4-fpSmbyYnVo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-40958-4@http.gcc.gnu.org/bugzilla/>
References: <bug-40958-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01235.txt.bz2

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |REOPENED

--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #12)
> Joost, is it fixed after revision 198023? If yes, could you close the PR as
> FIXED?

With the introduction of the temp buffer for parsing modules the excessive
lseek() calls have been eliminated, and with the introduction of compressed
module files the total size of module files on disk have been reduced by an
order of magnitude for large projects.

However, the fundamental(?) issue of module sizes growing exponentially with
deep module hierarchies still remains. The solution to that is to not include
transitive dependencies, which in turn would require a module cache for good
performance. Whether that is worth doing, and who is willing and able to do it,
is unclear.