On Fri, Sep 03, 2021 at 03:33:55PM -0500, Chris Muller wrote:
> Hi Levente,
> 
> An easy way to avoid that would be to write directly into the file stream,
> > but Squeak's file streams are not write-buffered
> >
> 
> Hm, I always thought they were.  A quick script I used to verify:
> 
> | ws rs |
> nil assert: (FileDirectory default fileExists: 'writebuffered') not.
> FileDirectory default deleteFileNamed: 'writebuffered'.
> [ws := FileStream fileNamed: 'writebuffered'.
> rs := FileStream readOnlyFileNamed: 'writebuffered'.
> ws nextPutAll: '12345678901'.
> "Assert only buffered, not written"
>    nil assert: (rs next: 10) isEmpty.
> "Force physical write"
>    ws flush.
> "Assert written"
>    nil assert: (rs next: 10) = '1234567890' ] ensure:
> [ ws ifNotNil: [ws close].
> rs ifNotNil: [rs close] ]
> 
>  - Chris

Hi Chris,

That's the buffering from the stdio C runtime library, which
is used by the unixy VMs (but not Windows).

Despite that level of buffering, Squeak's I/O to file streams
is very slow when reading and writing in small chunks, such
as byte-by-byte (which happens to be a very common use case).
If someone wanted to take on a project to improve Squeak's
overall performance, profiling and improving the file I/O
performance would be some "low hanging fruit".

BTW, I do not know which is better overall - the buffered C
runtime approach of the unixy VMs, or the direct write approach
of the Windows VM. As far as I know, nobody has ever done a
controlled test to find out. I personally suspect that the
approach that Andreas took for Windows may give better performance
over a range of real-world applications, but that is only a
guess on my part.

Dave