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 :)



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 :)


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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091127/69ab3065/attachment.htm