On 18.05.2011 14:53, Sven Van Caekenberghe wrote:
Mariano,
On 18 May 2011, at 14:29, Mariano Martinez Peck wrote:
Sven, I improved quite a lot using your buffered write stream.
What I don't understans is why MultiByteFileStream doesn't perform as good as
them.
If I see StandardFileStream has an internal buffer called 'buffer1'.
So why is that much difference between using MultiByteFileStream directly and
a WriteStream (ByteArray new writeSteam ) or ZnBufferedWriteStream ?
Because actually writing to file is expensive.
MBFS does it on every nextPut/nextPutAll: send, ZnBuffered only when
asked to/buffer fills.
I just looked briefly at the hierarchy, it seems that buffer1 is an output
buffer of size 1 !
Have a look at
StandardFileStream>>#nextPut: char
"Write the given character to this file."
rwmode ifFalse: [^ self error: 'Cannot write a read-only file'].
collection ifNotNil: [
position< readLimit ifTrue: [ self flushReadBuffer ] ].
buffer1 at: 1 put: char.
self primWrite: fileID from: buffer1 startingAt: 1 count: 1.
^ char
There is simply no buffering going on.
buffer1 is a mystery to me ;-)
Sven
The primitive requires an object of variableByte type.
If you didn't have a buffer1, you'd need to create a new 1-element
ByteArray/String on every call to nextPut: ;)
As for the primitive call always flushing to file, that is a decision
which have arguments both in favor and against it.
I wasn't there when it was written, so have no idea why they weighed one
over the other.
If I were to guess, I'd say PLS ("But I wrote it to file! Why isnt it
there yet when I open it??") and deterministic behaviour won over
performance.
Changing it now would probably mean quite a few changes to f.ex. source
management if you want the same level of recoverability you are ensured now.
That does not mean a buffering of write stream should not be available,
of course.
There are so many ways to do that though it quickly turns into painting
a bikeshed.
Cheers,
Henry
