You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to run your benchmark with my binary-parser, i noticed that in your benchmark there are lots of single combinator benchmarks which only repeat once, this give library like binary a huge disadvantage because binary do the offset counting in outer loop, see haskell/binary#124 for detail.
You can argue that's the part of the benchmark, but I think maybe we should at least add replicateM 10 or something to make the bench fair.
Another problem is cereal's getByteString is doing a copy which screws the result, because creating a pinned memory is way too slow, we should just use getBytes here.
The text was updated successfully, but these errors were encountered:
Thanks! I start binary-parsers as an experiment to find how much time attoparsec's mutable buffer approach can save, but binary performs incredible fast which leads me to re-read binary's source code, and lead to some further optimizations.
Binary's design is a really interest case, if you don't use backtracing combinators like <|> or lookAhead, you won't paying any book keeping. It definitely changed my view on how parser combinator works. That been said, from the binary's code, it seems it focus on performance on large rather then small: complex parsers running on large lazy ByteString input. But i think small cases is still important.
I'm trying to run your benchmark with my binary-parser, i noticed that in your benchmark there are lots of single combinator benchmarks which only repeat once, this give library like binary a huge disadvantage because binary do the offset counting in outer loop, see haskell/binary#124 for detail.
You can argue that's the part of the benchmark, but I think maybe we should at least add
replicateM 10
or something to make the bench fair.Another problem is cereal's
getByteString
is doing a copy which screws the result, because creating a pinned memory is way too slow, we should just usegetBytes
here.The text was updated successfully, but these errors were encountered: