[m-dev.] streams in Mercury

[Peter Ross]

On Wed, Dec 14, 2005 at 04:54:01AM +1100, Julien Fischer wrote:
> 
> On Wed, 14 Dec 2005, Ian MacLarty wrote:
> 
> > On Wed, Dec 14, 2005 at 02:58:26AM +1100, Julien Fischer wrote:
> > > Some initial comments/questions:
> > >
> > > How similar are the stream typeclasses to the stuff in extras/stream?
> > >

Just minor changes.

> > > ...
> > >
> > > > Are there any thoughts on this idea?
> > >
> > > Search for streams on the mailing list archive.
> >
> > There were a lot of results.  I didn't see anything to suggest my
> > proposal is a bad idea.
> >
> 
> My point was that there has already been a good deal of discussion
> about streams and associated issues.
> 
It was a long time ago we discussed this, from what I remember the
consensus was try out my design and see how it works and then report
back.  Consider this the report back. ;)

In fact we have used it extensively now and it works well.  There is
only one slight hack and that is we had to define write_string as a
typeclass method, as writing one char at a time to sockets is incredibly
expensive.

We currently use it for sockets, ssl and logging what we are writing
over our ssl stream to a file.


> > > > I thought of using the new MercuryFile C type, but that approach has two
> > > > problems:
> > > >    1.  It requires writing C code to implement a new type of stream.
> > > >    2.  It requires the compiler to be built with a special flag to turn
> > > >        on the use of this structure.
> > > >
> > >
> > > We could use the MercuryFile structure by default, although the question
> > > then becomes what sort of overhead is that going to entail?  Do MC have
> > > any figures on how the MercuryFile struct compares to normal files?
> > > (If not then that can be another job for Samrith ;-))
> > >
> >
> > The overhead ratio will depend on what kind of stream you're writing to.
> >
> 
> I was referring to stdin and stdout.
> 
For the MercuryFile the overhead will be one extra pointer lookup to
find which underlying C function to call no matter what the underlying
stream is.  So very slight.

> > Using MercuryFile you will always have to do a pointer lookup, but using
> > typeclasses presumably you could specialise the dereference away for
> > common instances.
> >
> 
> You may be overestimating how well we optimize code involving
> typeclasses.
> 
However it is possible to optimize away this overhead, but maybe it's not
implemented yet. So I don't think this is a good reason to not use a
stream typeclass.

So for me, I'm willing to pay the slight performance penalty and then
have someone work on getting rid of it if the optimization doesn't
exist.

Pete
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------