Re: Faster reader (Re: Startup time in guile-1.3 (II))

[Greg Harvey <Greg.Harvey@thezone.net>]

hjstein@bfr.co.il (Harvey J. Stein) writes:

> Craig Brozefsky <craig@onshore.com> writes:
> 
>  > Mikael Djurfeldt <mdj@nada.kth.se> writes:
>  > 
>  > > I think, maybe, that the win in this case (being able to treat files
>  > > opened for update in a simpler way than in the POSIX interface) is not
>  > > worth the cost involved in its implementation.  I suspect that this
>  > > holds even if we try to find a more efficient implementation.
>  > 
>  > My understanding is that this allows safe read and write to the same
>  > port without the user having to flush in between to accommodate for
>  > losing STDIO implementations.  If we remove this then we are requiring
>  > users to flush if they want their code to be robust on all platforms.
>  > Since I do not recall a "flush" procedure to be called on ports in
>  > R[45]RS, tho perhaps I just missed it, this would mean not
>  > implementing R[45]RS portably in Guile, and not maintaining basic
>  > scheme semantics.  Our users should not have to worry about that.
>  > 
>  > > I plead for dropping this change entirely.
>  > 
>  > I do too, but only by replacing it with a fix that maintains the
>  > present user interface, and performs better, ie, the re-implementation
>  > of STDIO buffering that Jim mentioned in his previous post.  In the
>  > meantime perhaps a check to see if your on a lame platform or not in
>  > the compilation of guile would reduce it's impact on everyone by
>  > sparing those with a real STDIO the agony.
> 
> You've got this structure of functions for reading & writing to each
> port.  Why not stick the fast set in when it's not opened for
> read/write & the slow flushing one in when it is?
> 
> BTW, can anyone explain to me why one would want to implement
> buffering directly instead of using stdio?

I'd think mostly to avoid these performance problems with braindead
stdio implementations, and to stop from discriminating against smart
ones that don't need a flush between read & write. If not, you end up
with 'guile is so slow on foo' (assuming there's a time when foo !=
every platform guile runs on >;). A buffering implementation in guile
should work well everywhere.

Other benefits; it can be more taylored to the requirements of scheme
(I guess it might be easier to implement ungetting & stuff); allow
buffering for more than just normal files without too much effort;
make it easier and more reliable to turn buffering off and on when
necessary. Perhaps it could be tied in to the idea of providing emacs
style buffers for guile, but that might introduce a lot of overhead
for simple reading and writing on files.

-- 
Greg