[squeak-dev] Faster FileStream experiments

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Nov 26 22:48:42 UTC 2009


2009/11/18 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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.
>
> Just want to wish you every encouragement!  This is *really* useful work.

I just throw an un-tested minimal read/write version of BufferedFileStream.
Beware, I just wrote from scratch and did not even run one single
method since the read/write refactoring...
So far, I did rather spend my spare time in commenting the
implementation (see class comment too)...
If some good souls want to analyze/try it.
It should be reasonably optimized for readOnly and random read/write cases.
For append only, that might not be optimal due to useless attempts to
read past end, but that should not cost that much. For read/append,
there is probably room for more efficiency too, but major improvment
vs StandardFileStream should already show up. Not sure we really need
to introduce these optimizations.

The path to a cleaner/faster stream library is longer than just this
little step.
Beside testing, we'd have to refactor the hierarchy, insulate all
instance variables, and delegate as much as possible as Igor
suggested.
We'd better continue on the cleaning path and not just add another
FileStream subclass complexifying a bit more an unecessarily complex
library.

Nicolas

>>
>> Nicolas
>>
>>
>>
>
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BufferedFileStream.st
Type: application/octet-stream
Size: 13620 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091126/4eced268/BufferedFileStream.obj


More information about the Squeak-dev mailing list