[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