aeson
aeson copied to clipboard
haskell
Consider reimplementing `Encoding` using the "jsonifier" lib
According to the benchmarks of "jsonifier", it provides a performance boost in encoding of up to 3x over the current implementation of "aeson".
It has been suggested by @bergmark to consider updating "aeson" to reuse "jsonifier" for its encoding functionality.
"jsonifier" uses a lot of C under the hood, so this is one thing you'll have to take notice of for users coming from GHCJS. As an idea regarding that, the "jsonifier" dependency could be made optional being controlled by a Cabal flag.
In case you guys find yourselves interested, I'm open to provide the necessary support on the "jsonifier" end. E.g., by providing encoders for extra types like those from the "time" lib and things like that.
A single microbenchmark vs. additional complexity?
I'm sceptical. Let the jsonifier prove itself first.
EDIT: as far as I can see, nothing prevents from building an aeson like API for jsonifier so e.g. servant users can swap builtin JSON to another one which would use jsonifier instances for encoding. I don't see a reason why such experimentation should be driven from inside of aeson when it can be done externally first.
I'm also worried about two-pass strategy.
When the data is big, and/or contains structures which are build-on-demand yet not single thunks (like Coyoneda or Codensity like things, which is fast to construct but each traversal is new one i.e. expensive), how well jsonifier performs?
I'd be less hesitant about single-pass (but-faster-then-Builder-based) implementation.
I absolutely don't mind not rushing and giving it time for jsonifier to prove itself in actual cases before taking any action in "aeson". That is simply wise. I've mostly posted here to express my openness to cooperate.
Extending "jsonifier" benchmark suite to cover more cases would be useful for the package on its own, not just for any decisions regarding "aeson". So I'm open for suggestions on that as well.
Concerning extending "jsonifier" to mirror the "aeson" API, I'll have to decline that, because one of the purposes of "jsonifier" is to provide an alternative approach to producing JSON. However it's still possible to achieve by releasing another package, which will provide an "aeson"-like API over "jsonifier". I just am not going to participate in that.