[MIT-Scheme-devel] Faster ports.

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Wed, 22 Jun 2011 19:34:32 +0000
> 
> [...]
>    I had to do a violence to generic-i/o performance, I'm afraid.
> 
> We need to do violence to the port system to get any performance out
> of it.  Binary ports should be buffered by default, so that
> READ-OCTET can be open-coded, with unbuffered ports as a special
> case of buffered ports, and character I/O should be layered on top
> of that.  Right now everything is optimized for the character I/O
> case at the expense of the binary I/O case.

If a port-type has slots for methods like octet-ready? and read-octet
(instead of char-ready? and read-char), how do we open-code read-octet?

You would perhaps like to see read-octet expand into in-line code that
expects a buffer immediately at hand (via port slots), and that only
applies a port-type method when the buffer is empty/full?  With some
care, the in-lined code could work equally well on internal OR
external buffers.

How about calling them "bytes"?  It is shorter than "octets", yes?

> You're right that we'll need to use buffers outside the heap to talk
> with, e.g., aio, or any other asynchronous I/O system provided by the
> operating system.  That will be necessary only for the buffers of
> ports that do I/O with the outside world, of course, not ports
> internal to Scheme.

I can work on genio.scm some more if this async i/o support is welcome
in master.  Presumably a new make-generic-ASYNC-I/O-port procedure can
be used by e.g. open-input-gfile -- when an external buffer is
required.  Make-generic-I/O-port can then stay optimized for internal
buffers.  Existing sources/sinks should not need to change.

If buffer transfers are all inlined via integrable calls to READ-OCTET
etc., will our ports smoke?  Did you have something else in mind?