Here's a completely different question:

One stumbling block for maximal performance in the Primitive I/O layer
is the fact that it uses ordinary octet vectors to write into.  This
has two potential problems:

- The octet vector may not have the optimal alignment for the
  underlying OS I/O.
- The octet vector may be movable by the underlying GC, which is bad
  for OS substrates such as Windows with asynchronous I/O, which
  expect a buffer to stay in a fixed location.

(Sebastian Egner and I came up with this issue independently.)

Now, this doesn't justify introducing an entirely new type for I/O
buffers, because it would mean extending the API at all levels for
negligible gain in the common case.

However, maybe it be worthwile to add a procedure to the Primitive I/O
layer like so:

(make-i/o-buffer size) -> u8vector

The Primitive I/O operations would still be required to work on
"ordinary" u8vectors, but could do the job more efficiently if handed
one of the above.  An implementation would be free to do

(define (make-i/o-buffer size)
  (make-u8vector size))

or could supply a tuned implementation that provides proper alignment
and/or locks the u8vector to a fixed location in memory.

Opinions?

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla