{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiex3a6apbxjjwkmz7cfdszpvgtnnoyyubyusfasdg5wmreqfh3s4i",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mgf43gxyaex2"
  },
  "path": "/t/changing-the-binary-instance-for-double-and-float/13758#post_20",
  "publishedAt": "2026-03-06T09:54:24.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "fpco"
  ],
  "textContent": "For context, quick search yields benchmarks from a decade ago (fpco, haskell-perf), though I don’t expect much has changed since.\n\nelaforge:\n\n> was the stuff about binary being slow actually true?\n\n“slow” doesn’t mean much in a well-written parser, they come with trade-offs:\n\n  * Anything small will always be faster in an input-strict parser, since those work over a single continuous chunk of memory. Conversely anything huge may be handled more efficiently in an input-lazy parser;\n\n  * A parser that supports streaming output can be used for incremental processing, and you’re kinda screwed otherwise if you need that;\n\n  * Big data blobs (such as videogame resource files) can be parsed way more efficiently by memory-mapping the file and parsing each section in parallel (though memory-mapping is a platform-specific feature, so it’s a pain in the butt to set up).\n\n\n\n\nIn my experience `binary` parses a 35MB GameMaker resource file in a fraction of a second (~65ms as I check right now), so it’s more than fast enough for general use.",
  "title": "Changing the `Binary` instance for `Double` and `Float`"
}