[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Joost VandeVondele changed: What|Removed |Added Depends on||40958 --- Comment #21 from Joost Van

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Jerry DeLisle changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot|unassigned at gcc dot |

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #19 from Janne Blomqvist 2011-12-01 14:12:45 UTC --- Author: jb Date: Thu Dec 1 14:12:37 2011 New Revision: 181879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181879 Log: PR 25708 Avoid seeking when parsing strings and whe

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #18 from Joost VandeVondele 2011-12-01 07:29:25 UTC --- Janne's latest patch now effectively 'removes' lseek: 26.840.108906 0242658 madvise 20.120.081608 045 read 19.27

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #17 from Joost VandeVondele 2011-11-30 19:50:37 UTC --- Janne's lseek patch: http://gcc.gnu.org/ml/fortran/2011-11/msg00251.html has further nice results on CP2K (CP2K_2009-05-01.f90) Thomas (trunk): 92.084.963429 0 1

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Jerry DeLisle changed: What|Removed |Added AssignedTo|pault at gcc dot gnu.org|jvdelisle at gcc dot |

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Janne Blomqvist changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot|pault at gcc dot gnu.org

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #14 from Jerry DeLisle 2011-04-05 05:24:46 UTC --- Here is an strace summary. There is something afoot here: % time seconds usecs/call callserrors syscall -- --- --- - - -

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Jerry DeLisle changed: What|Removed |Added AssignedTo|pault at gcc dot gnu.org|jvdelisle at gcc dot |

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #12 from Tobias Burnus 2011-04-04 12:27:28 UTC --- (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

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #11 from Paul Thomas 2011-04-04 11:49:52 UTC --- (In reply to comment #10) > I would like to promote this one. I have run into an application that is > taking about 2 to 3 minutes to compile while other compilers can do so in a > mat

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot |

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #9

[Bug fortran/25708] Module loading is not good at all

--- Comment #8 from pault at gcc dot gnu dot org 2007-05-02 08:41 --- (In reply to comment #7) > BTW, here's some slides describing NAG:s experience, they use lazy symbol > lookup combined with caching, and claim it is up to 1000 times faster than > non-lazy (which gfortran uses AFAICS).

[Bug fortran/25708] Module loading is not good at all

--- Comment #7 from jb at gcc dot gnu dot org 2007-04-25 09:41 --- BTW, here's some slides describing NAG:s experience, they use lazy symbol lookup combined with caching, and claim it is up to 1000 times faster than non-lazy (which gfortran uses AFAICS). http://www.fortran.bcs.org/2007/

[Bug fortran/25708] Module loading is not good at all

--- Comment #6 from pault at gcc dot gnu dot org 2007-01-15 10:27 --- This is the one that I said that I would take on for the next few months. I will try to implement the manifesto in #5 and have the F2003 specification for sub-modules with me. Paul -- pault at gcc dot gnu dot org

[Bug fortran/25708] Module loading is not good at all

--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-10-31 08:29 --- Subject: RE: Module loading is not good at all FX > -Message d'origine- > De : fxcoudert at gcc dot gnu dot org > [mailto:[EMAIL PROTECTED] > Envoyé : mardi 31 octobre 2006 08:01 > > I like th

[Bug fortran/25708] Module loading is not good at all

--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-31 07:00 --- (In reply to comment #2) > I have proposed to introduce module namespaces that are built just once per > compiled file per module; either from source or a mod file. Subsequent usage > can lift the symbol informat

[Bug fortran/25708] Module loading is not good at all

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:23 --- Confirmed and marked as an enhancement. After all, it's working :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/25708] Module loading is not good at all

--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-01-09 07:36 --- Subject: RE: Module loading is not good at all Andrew, > --- Comment #1 from pinskia at gcc dot gnu dot org > 2006-01-07 05:10 --- > Looking at the profile for PR 21130 makes me think fixing

[Bug fortran/25708] Module loading is not good at all

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-07 05:10 --- Looking at the profile for PR 21130 makes me think fixing this bug will also fix that one. Oh. it is just as bad if we have module modulef declared in the same file as we have to save it and then reload it which is j