[Haskell-cafe] Iteratee-like

Permjacov Evgeniy permeakra at gmail.com
Wed Dec 15 19:11:47 CET 2010

On 12/15/2010 05:48 PM, John Lato wrote:
>     From: Permjacov Evgeniy <permeakra at gmail.com
>     <mailto:permeakra at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20101215/88e02cb5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testLIO.hs
Type: text/x-haskell
Size: 311 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20101215/88e02cb5/attachment.hs>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testR2I.hs
Type: text/x-haskell
Size: 431 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20101215/88e02cb5/attachment-0001.hs>

More information about the Haskell-Cafe mailing list