Re: [Patch, libgfortran] PR25949 Excessive memory usage due to buffering.

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Wed, Jan 25, 2006 at 07:29:40PM -0800, Jerry DeLisle wrote:
> Janne Blomqvist wrote:
> >
> >Attached patch fixes one case I found were the library uses excessive
> >memory.
> >
> >It also avoids calling lseek() unless necessary just before a read()
> >or write(). This should fix an issue brought up by Bud Davis a long
> >time ago, where unformatted sequential performance was slow on NFS due
> >to the need to lseek() back and fix the record size, and then lseek()
> >forwards to the end of the record again. As long as the markers and
> >the record fits in the buffer, this is no longer an issue with this
> >patch. Unfortunately there is still one unnecessary lseek():in
> >occuring per record, so it's not optimal yet.
> >
> >Also some minor cleanup/simplification.
> >
> This passed all NIST tests except fm311.f which is an unrelated compile 
> error.
> 
> As far as 4.1 goes, I thought the discussion was to keep 4.1 and 4.2 synced 
> as close as possible so it does not get too difficult to backport patches 
> later.  I am not an approver of course, but would vote for moving it to 4.1 
> as soon as makes sense.  (It can't hurt)
> 

I agree with the "keeping 4.1 and trunk in sync" ideal.  However,
4.1 is approaching release and we need to be fairly careful with
introducing regressions and other build problems.

As to fm311.f, there is very specific language in Section 14 of standard
on which names conflicts with the names a common block.  For example, a
named common block's name cannot be a standard intrinsic procedure name.
I don't have time to look into this until Saturday.

-- 
Steve