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

[Jerry DeLisle <jvdelisle at verizon dot net>]

Jerry DeLisle wrote:
> Janne Blomqvist wrote:
>
> > Hi,
> >
> > 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.
> >
> > Regtested on i686-pc-linux-gnu. Ok for trunk? It's a quite minor fix
> > after all, so I don't think it should go into 4.1.
> 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)
>
> Jerry
I am not sure if two votes for me is sufficient, but I reviewed Janne's patch in 
detail tonight.  Very nice.  Really cleans up the code.  Passes all the tests. 
(regression and NIST, including fm311.f with Pauls patch on the frontend). And I 
will be bold and say I understand it.

I can see where we can do some clean up on the read side as well, next step.

I think it is OK for trunk and after a few days I would go for 4.1 if we are not 
frozen yet and if more senior folks don't object.

Regards,

Jerry