Buffered streams (was: RE: [Win32] VM Update for 2.7/2.8)

Andres Valloud avalloud at exobox.com
Thu May 25 00:42:05 UTC 2000


Hi Andreas.

> > 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.
>
> Have you considered making block operations unbuffered?! Something like
> aFileStream nextPutAll: (String new: 1000) doesn't have to be buffered -
> it's really all the small #next/#nextPut: variants that should be buffered.

Buffering block writes is always bad.

> E.g., something like:
>
> BufferedStream>>nextPutAll: aCollection
>         dirty ifTrue:[self flushBuffer].
>         self primNextPutAll: aCollection.
>
> should reduce the overhead to something nearly unmeasurable.

It's not that easy. You have to send position: because you were buffering for
next and nextPut:. Then you write with primWrite:from:startingAt:count:.
Finally, you have to update your own cached position, possibly increasing your
readLimit because you have just appended some stuff.

Let's consider this scenario too. Suppose you have a dirty buffer from 0 to
100. Then you set the position 200 and send nextPutAll:. So you shouldn't
flush.

Andres.





More information about the Squeak-dev mailing list