On 03.12.2012 12:10, Henrik Sperre Johansen wrote:
On 03.12.2012 09:30, Sven Van Caekenberghe wrote:
On 03 Dec 2012, at 07:25, Sven Van Caekenberghe <[email protected]> wrote:
Hi Mariano,
On 02 Dec 2012, at 23:43, Mariano Martinez Peck
<[email protected]> wrote:
This is really really interesting, because it means a speed up of
2x when reading :)
Where can I get the last version of ZnBufferedReadStream?
I knew you would be interested: it is in the latest Zn, either
http://mc.stfx.eu or squeaksource (not in the metacello yet).
It should work on binary streams too, I don't know whether it would
make a lot of difference, I would guess so.
Maybe Fuel uses lots of 'deterministic reading' (size prefixed)
instead of parsing.
Well, I just tried. The good news is, it works, the bad news is, it
does not make a difference, either way:
| data |
data := STONTestMap classTreeExtended.
[ FLSerializer serialize: data toFileNamed: '/tmp/all.fuel' ]
timeToRun. 4967
[ FLMaterializer materializeFromFileNamed: '/tmp/all.fuel' ]
timeToRun. 1095
[ '/tmp/all.fuel' asFileReference readStreamDo: [ :fstream |
ZnBufferedReadStream on: fstream binary do: [ :stream |
FLMaterializer newDefault materializeFrom: stream ] ] ]
timeToRun. 1043
So I guess Fuel is already pretty optimised, especially for reading ;-)
I think ZnBufferedReadStream only makes a difference for parsers that
are sending lots of little #next, #peek and #atEnd messages in loops.
Binary protocols are typically more deterministic, they know ahead
what they have to read and don't have to do #peek or #atEnd tests all
the time.
Sven
--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill
The reduced read times you are seeing, is lack of decoding, not lack
of buffering.
BufferedReadStream uses readInto:startingAt:count:, which isn't
reimplemented for MultiByteFileStream to do proper decoding, and thus
inherits the one from StandardFileStream.
The filestreams already do read buffering (albeit with a smaller
buffer size), so when Fuel uses binary mode (which skips decoding),
the performance is pretty much the same.
Cheers,
Henry
In other words, to get comparable runtimes, you'd have to include a
ZnEncodedStream doing UTF-8 decoding on top of the stack used by the
STON-reader.
(At which point you're well on the way to reimplementing the modular
streams of Xtreams, but with a more traditional API :) )
Cheers,
Henry
