>David,
>
>>  > If Squeak had buffered file io in the smalltalk layer this type of
>>  > test would of course run faster.
>>
>>  I wonder if that's actually the case. Most of the Squeak VMs are using
>>  the stdio library for file IO, which is already buffered, and which on
>>  many platforms is already making use of an OS buffer cache.  Adding
>  > another layer of buffering in Smalltalk might just slow things down.

Well keep in mind the amount of buffering that stdio by default does 
is quite small, if in fact the stdio logic actually does buffering 
(milage might vary). Besides if it is in Smalltalk then people can 
tinker.

A quick glance at the os-x source code shows _IO_BUFSIZ defined as 1024.
But I'd bet hard drives are happier dealing with at least 64K for 
read/write operations.

Now that's the C code, goodness knows what the operating system is 
doing with readahead and the like.

At 9:49 AM -0500 5/11/02, Jimmie Houchin wrote:
>John mentioned io buffering in his message. I guess Linux does it 
>and Windows doesn't (OS level). The code I wrote which on Squeak was 
>4 times faster than Python on the Linux machine. I tried it on 
>WindowsME and here are the results.
>
>Python average about 3 seconds.
>Squeak with the new code below.
>33238
>32220
>32276
>32349


I'm curious if you are reading and writing the entire chunk in one 
operation with a  standard file stream. Taking 32 seconds to do the 
read/write is excessive. I wonder if a full GC event with paging is 
going on to affect your numbers. I would have expected something < 
2-3 seconds so seeing 32 seconds has a very wrong feel to it.

Maybe some other windows user can try it?



-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================