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

Raab, Andreas Andreas.Raab at disney.com
Wed May 24 20:49:03 UTC 2000


Andres,

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

That's my experience too.
 
> 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.
E.g., something like:

BufferedStream>>nextPutAll: aCollection
	dirty ifTrue:[self flushBuffer].
	self primNextPutAll: aCollection.

should reduce the overhead to something nearly unmeasurable.

  - Andreas





More information about the Squeak-dev mailing list