On Tue, Mar 26, 2013 at 7:23 PM, Thomas Koenig wrote:
> Am 26.03.2013 16:24, schrieb Tobias Burnus:
>
>
>> I wonder whether one should also do what Joost has proposed:* Changing
>> "allocatable" to "al" etc. That reduces both the .mod file size (and
>> thus I/O and improves caching) and the memory
On Tue, Mar 26, 2013 at 5:08 PM, Mikael Morin wrote:
> Le 24/03/2013 22:58, Janne Blomqvist a écrit :
>> The attached patch takes the crude approach of first sequentially
>> reading the .mod file into a temporary buffer, then does the actual
>> parsing from that buffer.
>>
> I don't like it much,
Am 26.03.2013 16:24, schrieb Tobias Burnus:
I wonder whether one should also do what Joost has proposed:* Changing
"allocatable" to "al" etc. That reduces both the .mod file size (and
thus I/O and improves caching) and the memory consumption of the
compiler with the proposed caching scheme. As c
Mikael Morin wrote:
Le 24/03/2013 22:58, Janne Blomqvist a écrit :
The attached patch takes the crude approach of first sequentially
reading the .mod file into a temporary buffer, then does the actual
parsing from that buffer.
I don't like it much, but knowing how bad module files are currently
Le 24/03/2013 22:58, Janne Blomqvist a écrit :
> The attached patch takes the crude approach of first sequentially
> reading the .mod file into a temporary buffer, then does the actual
> parsing from that buffer.
>
I don't like it much, but knowing how bad module files are currently
handled, it's
Hi,
gfortran's handling of .mod files leaves a lot to be desired. One
problem being that the parsing of the module is done in such a way
that we seek back and forth in the file; see e.g. comments in PR
25708. This not only causes us to spend unnecessary time executing
lseek syscalls, but we also r
