On Thu, Dec 16, 2010 at 12:23 AM, Permjacov Evgeniy <span dir="ltr">&lt;<a href="mailto:permeakra@gmail.com">permeakra@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  
    
  
  <div bgcolor="#ffffff" text="#000000"><div class="im">
    On 12/15/2010 05:48 PM, John Lato wrote:
    </div><div class="im"><blockquote type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">From: Permjacov Evgeniy &lt;<a href="mailto:permeakra@gmail.com" target="_blank">permeakra@gmail.com</a>&gt;<br>

          <br>
          current links<br>
          <br>
          <a href="https://github.com/permeakra/Rank2Iteratee" target="_blank">https://github.com/permeakra/Rank2Iteratee</a><br>
          <a href="https://github.com/permeakra/PassiveIteratee" target="_blank">https://github.com/permeakra/PassiveIteratee</a><br>
          <br>
          The main difference from &#39;original&#39; iteratees I read about is
          that both<br>
          do not use &#39;chunks&#39; and pass data one-by-one. So, what I wrote
          may be<br>
          slower, but should be easier to maintain and more transparent
          for ghc<br>
          optimising facilities. I wanted as clean and simple code as
          possible,<br>
          but it is still very, very messy at some places and I want it
          cleaner.<br>
          Any suggestions? I also want to check, how good ghc does its
          work with<br>
          this messy modules. They may become interesting benchmarks.<br>
        </blockquote>
        <div><br>
        </div>
        <div>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&#39;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.</div>
      </div>
    </blockquote></div>
    Ok, I tested with ByteString chunks and got roughly the same
    performance (less then 5 % difference) as with Data.Iteratee (as
    expected, as it is not a monad a bottlenec when using chunks).
    However, with Word8&#39; streams I slows down to point six times slower
    then lazy IO. this is still may be acceptable if IO actions has to
    be performed while making nontrivial list fusions, but in general it
    is fail. <br></div></blockquote><div><br></div><div>Disappointing, but I&#39;m not surprised.  I think getting good performance is possible in principle, but currently there&#39;s something missing from the implementations.  Whether work needs to be done on GHC&#39;s optimizer or the iteratee code, I can&#39;t say.  Honestly I&#39;m not too interested in pursuing this myself now, but if somebody else wants to it could be fruitful.</div>
<div><br></div><div>John</div></div>