Hi Nicholas,<div><br></div><div> 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...</div>
<div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>t1 is nextLine over the sources file via StandardFileStream</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>t2 is nextLine over the sources file via BufferedFileStream</div>
<div><span class="Apple-tab-span" style="white-space: pre; "> </span>t3 is next over the sources file via StandardFileStream</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>t4 is next over the sources file via BufferedFileStream</div>
<div><br></div><div>Cog: an OrderedCollection(11101 836 9626 2306)</div><div><br></div><div>Normalizing to the first measurement: 1.0 0.075 0.867 0.208</div><div><br></div><div>Your ratios are 1.0 0.206 4.827 0.678<br><br>
</div><div>I'd say BufferedFileStream is waaaaay faster :)</div><div><br></div><div><br></div><div><br></div><div>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 :)</div>
<div><br></div><div><br><div class="gmail_quote">On Wed, Nov 18, 2009 at 3:10 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I just gave a try to the BufferedFileStream.<br>
As usual, code is MIT.<br>
Implementation is rough, readOnly, partial (no support for basicNext<br>
crap & al), untested (certainly has bugs).<br>
Early timing experiments have shown a 5x to 7x speed up on [stream<br>
nextLine] and [stream next] micro benchmarks<br>
See class comment of attachment<br>
<br>
Reminder: This bench is versus StandardFileStream.<br>
StandardFileStream is the "fast" version, CrLf anf MultiByte are far worse!<br>
This still let some more room...<br>
<br>
Integrating and testing a read/write version is a lot harder than this<br>
experiment, but we should really do it.<br>
<font color="#888888"><br>
Nicolas<br>
</font><br><br>
<br></blockquote></div><br></div>