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