The issue is not the unboxing. Rather, it's the fact that FreeT forces every step to go through the base monad.
Michael's solution is the idiomatic one. Unfortunately, what we really need is a more efficient FreeT that hides its internal implementation so we can skip passing things gratuitously through the base monad. On Wed, Aug 5, 2015 at 6:08 PM Tran Ma <ma.ngoc.t...@gmail.com> wrote: > Hi Michael, > > Yeah, I was worried about the FreeT too. Inspecting the Core does show > that it is boxing/unboxing FreeT for every chunk, but I wrote this off as > not a problem because there aren't that many chunks anyway. I mean, a big > chunk size (and thus fewer chunks) seemed to have no effect on the > performance of this code compared to smaller chunks. > > I think I'll try to write "chunkify" using IORefs and see how that > compares. > > Thanks, > > Tran > > On Thursday, 6 August 2015 11:02:24 UTC+10, Michael Thompson wrote: >> >> Dear Tran Ma >> >> Here's a couple of unhelpful remarks... >> >> The pre-cut library way of writing `chunks` is something like: >> >> import qualified Control.Foldl as L -- cabal install foldl >> >> chunks = L.impurely foldsM (fmap Chunk L.vector) (view (chunksOf >> 10) nums) >> >> It seems a little slower than your chunkify. The path via FreeT, though >> exactly right, >> is generally pretty expensive - at least in my experience. >> >> This is I think because the implementation in `free` is textbook-correct >> and gives >> the compiler very little room for specialization. For example, the simple >> expedient of >> defining `FreeT` with a separate `M` constructor, as Pipes.Internal does >> with `Proxy`, makes >> things much faster, since (as I think I have verified in the past) the >> compiler >> can make specializations and so on without immediately hitting a general >> `m (FreeF f (FreeT f m a))` >> >> I doubt that the indirection brought by `view` is causing much trouble; >> and of course >> it didn't matter much to switch to `Data.Vector.Unboxed`. >> >> This isn't much help for your problem of writing a good >> `Int -> Producer a m r -> Producer (Vector a) m r` I will look into it >> more. >> >> yours Michael T >> > -- > You received this message because you are subscribed to the Google Groups > "Haskell Pipes" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-pipes+unsubscr...@googlegroups.com. > To post to this group, send email to haskell-pipes@googlegroups.com. > -- You received this message because you are subscribed to the Google Groups "Haskell Pipes" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipes+unsubscr...@googlegroups.com. To post to this group, send email to haskell-pipes@googlegroups.com.
