File Performance Q.?

David T. Lewis lewis at mail.msen.com
Sat May 11 23:09:16 UTC 2002


On Sat, May 11, 2002 at 06:38:31PM +0200, Andreas Raab wrote:
> David,
> 
> When I ran a few benchmarks I always came up with at least a factor of
> two in advantage of internal buffering even if the OS does file
> buffering. Of course, if you have large read operations (starting
> somewhere around 1/4 buffer size) you should go straight to the file
> system but for small reads internal buffering has huge advantages.
> 
> > My completely untested speculation is that adding IO buffering in the
> > image would be useful for Squeak NOS, but not much else.
> 
> See above. Try it on your favourite platform to see how it behaves.

Well darn, who would have thought that idle speculation would end
up being such a poor predictor of actual results? ;)

On my Linux box, your buffered read test runs 2.6 times faster than
the unbuffered one if the FileStream is a CrLfFileStream, and 2.2
times faster for a StandardFileStream.

If the test is changed to read 5 character chunks rather than a
single character at a time, the buffered version is only 1.26 times
faster than the unbuffered one, about what I might have anticipated
if I were to indulge in some further idle speculation. But here's
something interesting: If you do the test with 5 character chunks and
use a CrLfFileStream, the buffered version is 6.5 times faster (!),
apparently due to a lot of time spent in String>>withSqueakLineEndings.

Here is the change I made to your test for the five character chunk test:

"using the OS buffering for files"
t1 := [fs := FileStream readOnlyFileNamed: Smalltalk changesName.
        [(fs next: 5) size == 0] whileFalse.
        fs close] timeToRun.

"using internal buffering"
t2 := [fs := FileStream readOnlyFileNamed: Smalltalk changesName.
        [fs atEnd] whileFalse:[
                cached := ReadStream on: (fs next: 4096).
                [(cached next: 5) size == 0] whileFalse.
        ].
        fs close] timeToRun.

Dave




More information about the Squeak-dev mailing list