The binary package is known ( store: a new and efficient binary serialization library ) to be much, much slower than what Haskell can do ( serialization/report.md at master · haskell-perf/serialization · GitHub ). Mostly it’s due to allocations which are necessary due to binary’s design. Years ago I once asked the library maintainers to change the statement on the package from “suitable for high performance scenarios” to something more realistic like “a solid reference implementation, but not efficient with respect to other options, like cbor, flatparse, attoparsec.” I think they agreed, but for whatever reason it didn’t make it in. So the scenario of people writing high performance things with binary and finding it’s really slow happens often.
Comparatively, flatparse was on par with Rust’s nom in one like-for-like benchmark I conducted a few years ago. I can dig that up if skeptical, but it stands to reason, the libraries make different trade offs.
I’ve audited the binary package when I was a consultant, and it was solid correctness-wise. But in my head it sits in a “correct but slow” box, alongside options making different trade offs with better perf.