> > From: Permjacov Evgeniy <permea...@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 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
