[squeak-dev] Faster FileStream experiments

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Nov 27 21:49:53 UTC 2009


2009/11/27 Eliot Miranda <eliot.miranda at gmail.com>:
> Hi Nicholas,
>     here are my timings from Cog.  Only the ratios correspond since the
> source file is of a different size, my machine is different, and Cog runs at
> very different speeds to the interpreter.  With that in mind...
> t1 is nextLine over the sources file via StandardFileStream
> t2 is nextLine over the sources file via BufferedFileStream
> t3 is next over the sources file via StandardFileStream
> t4 is next over the sources file via BufferedFileStream
> Cog: an OrderedCollection(11101 836 9626 2306)
> Normalizing to the first measurement: 1.0 0.075 0.867 0.208
> Your ratios are 1.0 0.206 4.827 0.678
>
> I'd say BufferedFileStream is waaaaay faster :)
>

Impressive.
I presume every Smalltalk message is accelerated while primitive call
remain expensive...

>
> P.S. your timing doit revealed a bug in Cog which is why it has taken a
> while to respond with the results :)  The doit's temp names are encoded and
> appended to the method as extra bytes.  The JIT wasn't ignoring these extra
> bytes, and your doit just happened to cause the JIT to follow a null pointer
> mistakenly scanning these extra bytes.  So thank you :)
>

Oh, you discovered my secret for finding bugs: (bad) luck

Nicolas

> On Wed, Nov 18, 2009 at 3:10 AM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>> I just gave a try to the BufferedFileStream.
>> As usual, code is MIT.
>> Implementation is rough, readOnly, partial (no support for basicNext
>> crap & al), untested (certainly has bugs).
>> Early timing experiments have shown a 5x to 7x speed up on [stream
>> nextLine] and [stream next] micro benchmarks
>> See class comment of attachment
>>
>> Reminder: This bench is versus StandardFileStream.
>> StandardFileStream is the "fast" version, CrLf anf MultiByte are far
>> worse!
>> This still let some more room...
>>
>> Integrating and testing a read/write version is a lot harder than this
>> experiment, but we should really do it.
>>
>> Nicolas
>>
>>
>>
>
>
>
>
>



More information about the Squeak-dev mailing list