Hi Andreas.

> Absolutely. We could get a big speed advantage during I/O given that we'd
> use a buffering file stream (rather than the current unbuffered version).
> Anyone care to do it?!

Craig Latta has done this, and I have done this too. My approach is much less
general than Craig's, it's a subclass of StandardFileStream.

My experience is that great improvement can be obtained from operations such
as next, nextPut:, position, position:, atEnd, etc. Combinations of those
methods can be expected to run at least 4 times faster.

On the other hand, things like nextPutAll: and nextInto: got from 1.2 to 3.5
times slower because of the additional overhead checking for buffer bounds and
dirtiness each time a block i/o operation is requested. I think it is almost
impossible to deal with this in a more efficient manner using just Smalltalk
code. Maybe I should give it another try, but I won't be able to do that right
away. I don't expect substantial improvement either.

My conclusion was that, at least inside Smalltalk, there's fast single element
transfers and fast block transfers. And you can't have them both, unless
better VMs cut the bound checking overhead for the buffer below actual i/o
time.

Andres.