On Sat, Mar 15, 2014 at 9:40 PM, Michael Thompson <[email protected]> wrote: > Ah I see. I made another version of `repeatedly` modeled on the io-streams > `Streams.parserToInputStreams` (but using `parseL` as a model) > http://lpaste.net/101263 > It has the type > > repeatedly :: Monad m > => Parser a -> Producer PB.ByteString m r > -> Producer a m (Producer PB.ByteString m r) > > I don't know if it fits with the general tenor of pipes-attoparsec, but it > fits with > the sort of picture Gabriel was suggesting for `pipes-text`. The 'error' > is just that we revert to the bytestring producer. (Oh, it occurs, I could > have > abstracted over bytestring v. text). Anyway, I mention it because, > using it for pipes2 in that revised module I get: > > > $ for i in streams pipes1 pipes2; do (echo $i && time ./iostreamsbench > $i); done > streams > 12500002500000 real 0m1.255s user 0m1.110s sys 0m0.035s > > pipes1 > 12500002500000 real 0m4.495s user 0m4.428s sys 0m0.065s > > pipes2 > 12500002500000 real 0m0.840s user 0m0.811s sys 0m0.028s > > which pleases.
Michael, all, I tried a couple of different approaches and I wasn't able to reach the performance of that `pipes2` you mention while still maintaining the current API that gives additional information about errors in case they happen, as there are a couple of checks I can't avoid making. I think maintaining this information is quite valuable. In any case, I was able to halve the time it takes to run the “pipes1” example in my computer: from ~4.57s to ~2.10s. The code is up in GitHub and Hackage now. You'll notice that there is a lot of similarity between the implementation of `parse`, `parseL`, `parsed` and `parsedL` now, as my attempts to abstract these lead either to less performant code or to hard to understand code, so I just implemented each of them individually without relying on each other. `parse` and `parsed` don't rely on `parseL` and `parsedL` because keeping the length accumulator has a significant cost when working with `Text`. Additionally, I changed the type of `parse` and `parseL` so that they now return `Nothing` when the underlying `Producer` is empty, just like `Pipes.draw`. Previously they would fail with a `ParsingError`. I've pushed all this to Hackage as `pipes-attoparsec-0.5`. Regards, Renzo Carbonara. -- 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 [email protected]. To post to this group, send email to [email protected].
