[m-dev.] for review: stream I/O

[Ralph Becket]

>From Peter Ross on 02/10/2000 16:38:57
> I didn't explain myself clearly enough.  The point is that if you want
> to provide functionality like line numbers and infinite putback you need
> somewhere to store this data and some efficient way of accessing it.
> This should be implemented at the Mercury level not at the C level which
> it is currently.  You are correct in that you should pay the cost for
> this functionality if you don't need it.

[I think you mean s/should pay/shouldn't pay/]

I agree that we should be able to supply wrapper types that supply
e.g. line number counting and infinite putback.  However, if it is
more efficient to implement these things at a lower level *and* it
is important to be efficient (as it is with the IO library) then I
think one should have the option of providing one's own implementation.
For example, the current io library does no buffering; maybe it should.
However, implementing buffering at the level of read_char//1 would be
pointless.

> > I'm not sure I understand.  Did you implement putback_char//1 in C and
> > get a slowdown or did you use a wrapper supplying putback_char//1 and
> > get a slowdown?  If it's the latter case, then I'm not surprised:
> > default and/or wrapper implementations should be expected to be more 
> > costly than `native' implementations.  If it's the former then I'm very
> > surprised since it should be no different than what we have in io.m now,
> > so I'd be interested to learn what was causing the problem.
> > 
> Depending on what stream type you are using you select the native method
> to call from a table of function pointers.  In otherwords the typeclass
> approach written in C.  That extra level of indirection caused a factor
> of three slowdown.

So the problem was not in how or where putback_char//1 was implemented,
but rather the overhead of doing a method lookup rather than a direct
call.  It seems to me that this is going to bite us no matter what we
do if we are going to use stream typeclasses - we can't avoid the cost
of method lookup if we can't decide at compile time which procedure to 
call.

That the cat program runs three times slower just due to the cost of
indirecting through a method lookup table staggers me.  It's an IO
bound problem!  Still, the sensible way to implement cat is not via a
read_char/write_char loop, but rather to use some more efficient
bulk IO operations implemented at a lower level (e.g. using write(2)
under POSIX).

Ralph

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------