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.
