jwlato at gmail.com
Wed Dec 15 15:48:08 CET 2010
> From: Permjacov Evgeniy <permeakra at gmail.com>
> current links
> 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe