Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve benchmark #6

Open
winterland1989 opened this issue Sep 22, 2016 · 2 comments
Open

Improve benchmark #6

winterland1989 opened this issue Sep 22, 2016 · 2 comments

Comments

@winterland1989
Copy link

winterland1989 commented Sep 22, 2016

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.

@Yuras
Copy link
Owner

Yuras commented Sep 23, 2016

I replaced getByteString with getBytes, and indeed cereal works much better now, thank you.

Re replicateM 10: now it becomes a pathological case for scanner :) I'll investigate it when I'll have time.

(BTW you are doing amazing work with binary-parse!)

@winterland1989
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants