> > After looking into problem (or rather onto your code) - the problem have
> > nothing to do with iteratee-compress I believe. I get similar behaviour
> > and results when I replace "joinIM $ enumInflate GZip
> > defaultDecompressParams chunkedRead" by chunkedRead. (The memory is
> > smaller but it is due to decompression not iteratee fault).
> >
>
> This is due to "printLines". Whether it's a bug depends on what the correct
> behavior of "printLines" should be.
>
> "printLines" currently only prints lines that are terminated by an EOL
> (either "\n" or "\r\n"). This means that it needs to hold on to the entire
> stream received until it finds EOL, and then prints the stream, or drops it
> if it reaches EOF first. In your case, the stream generated by "convStream
> consChunk printLines" is just a stream of numbers without any EOL, where the
> length is dependent on the specified block size. This causes the space
> leak.
>
> If I change the behavior of "printLines" to print lines that aren't
> terminated by EOL, the leak could be fixed. Whether that behavior is more
> useful than the present, I don't know. Alternatively, if you insert some
> newlines into your stream this could be improved as well.
>
> As a result of investigating this, I realized that
> Data.Iteratee.ListLike.break can be very inefficient in cases where the
> predicate is not satisfied relatively early. I should actually provide an
> enumeratee interface for it. So thanks very much for (indirectly)
> suggesting that.