<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/15/2010 05:48 PM, John Lato wrote:
<blockquote
cite="mid:AANLkTinNFcqqrBJGOzU2bHy-ckY9reRuxsPLib5GSLVB@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">From: Permjacov Evgeniy <<a
moz-do-not-send="true" href="mailto:permeakra@gmail.com">permeakra@gmail.com</a>><br>
<br>
current links<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/permeakra/Rank2Iteratee"
target="_blank">https://github.com/permeakra/Rank2Iteratee</a><br>
<a moz-do-not-send="true"
href="https://github.com/permeakra/PassiveIteratee"
target="_blank">https://github.com/permeakra/PassiveIteratee</a><br>
<br>
The main difference from 'original' iteratees I read about is
that both<br>
do not use 'chunks' and pass data one-by-one. So, what I wrote
may be<br>
slower, but should be easier to maintain and more transparent
for ghc<br>
optimising facilities. I wanted as clean and simple code as
possible,<br>
but it is still very, very messy at some places and I want it
cleaner.<br>
Any suggestions? I also want to check, how good ghc does its
work with<br>
this messy modules. They may become interesting benchmarks.<br>
</blockquote>
<div><br>
</div>
<div>Have you tried comparing it to either iteratee or
enumerator (which had mostly comparable performance last time
I checked, with a slight edge to iteratee)? Or to Oleg's
library? Try writing test cases, a simple byte-counting
application, or similar, so you can compare the performance
with the other versions. Both enumerator and iteratee include
demo programs that you could use as a starting point.</div>
</div>
</blockquote>
Ok, I tested with ByteString chunks and got roughly the same
performance (less then 5 % difference) as with Data.Iteratee (as
expected, as it is not a monad a bottlenec when using chunks).
However, with Word8' streams I slows down to point six times slower
then lazy IO. this is still may be acceptable if IO actions has to
be performed while making nontrivial list fusions, but in general it
is fail. <br>
<br>
Well, ghc has another complicated case for compiler optimisation
tests. <br>
<br>
CPS-style with rank2 types provides boost to performance, but when
using chunks it is insignificant, so haskell-98 version of iteratees
may be used with no worries.<br>
<blockquote
cite="mid:AANLkTinNFcqqrBJGOzU2bHy-ckY9reRuxsPLib5GSLVB@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>I agree that iteratees which work on a per-element level
are very clean and should be amenable to optimization by GHC.
It also shows a very clear relationship with stream-fusion
techniques. Unfortunately when I last tried it I couldn't get
acceptable performance. I was using ghc-6.12.1 IIRC, so it
could be different now.</div>
<div><br>
</div>
<div>John</div>
</div>
</blockquote>
<br>
</body>
</html>