On 12/15/2010 05:48 PM, John Lato wrote:
From: Permjacov Evgeniy <permeakra@gmail.com>

current links

https://github.com/permeakra/Rank2Iteratee
https://github.com/permeakra/PassiveIteratee

The main difference from 'original' iteratees I read about is that both
do not use 'chunks' and pass data one-by-one. So, what I wrote may be
slower, but should be easier to maintain and more transparent for ghc
optimising facilities. I wanted as clean and simple code as possible,
but it is still very, very messy at some places and I want it cleaner.
Any suggestions? I also want to check, how good ghc does its work with
this messy modules. They may become interesting benchmarks.

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.
I wrote a simple counter (attached,works for both variants of package), that literally counts bytes of given value in input. I got three-time slower result then with lazy io ( 0_o) with rank2types variant and six-seven time slower result with no CPS-version.  Looks like ghc is really good with list fusion... I'm still reading tutorial from iteratee package, so I have not compared with it yet. An equivalend lazy io programm attached. Can someone give an advice how to improve performance?

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.

John