From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21342 invoked by alias); 28 Nov 2011 14:24:36 -0000 Received: (qmail 21326 invoked by uid 22791); 28 Nov 2011 14:24:35 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Nov 2011 14:24:22 +0000 From: "Joost.VandeVondele at mat dot ethz.ch" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/40958] module files too large Date: Mon, 28 Nov 2011 14:37: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-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg02655.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #4 from Joost VandeVondele 2011-11-28 14:24:02 UTC --- Just for reference, compiling CP2K_2009-05-01.f90 results in 684 modules, stracing yields something like 12000 calls to open, and 148'847'399 calls to lseek. Clearly anything reducing the number of seeks is likely to have a good impact on compile time. For this particular case, caching modules would help a lot as well. However, our usual pattern is to have a single module per file, and all use statements at the top of the module. Caching would be of little help for this style. An efficient encoding of the information in the module would help. The idea of writing the module compressed, and decompressing it as a big string to memory for reading and parsing, seems appealing to me. Concerning a change of format, it would be important to keep one of gfortran's nice features, that is, the ability to use the modification time of the .mod files to avoid recompilation cascades. If .mod files would contain a reference to other .mod files (instead of containing the info directly), this property might be at risk.