jsonm
jsonm copied to clipboard
dbuenzli
Performance differences vs yojson
For a number of reasons, I'd prefer to use jsonm rather than yojson, but yojson is considerably faster. We noticed this in some internal benchmarks, which tracked pretty closely what came up in this blog post:
http://rgrinberg.com/posts/ocaml-json-benchmark/
According to that post, it takes about 2x the time, and allocates maybe 25x as much.
Is there any appetite for working performance of jsonm?
AFAIR yojson doesn't check encoding validity so I guess jsonm is bound to be slower.
Regarding allocation that's a bit surprising but I suppose is due to the internal continuation based monkey dance for supporting non-blocking scenarios. I'd gladly rewrite all this in direct style along these lines once we have effects in the language...
But before that actually happens maybe a little bit of profiling might uncover some stupid pattern in the implementation.
Also note sure exactly what your "reasons" are but jsonm is quite precise with location tracking for error reporting. If you don't really care about that maybe @seliopou's angstrom based json decoder is worth considering.
That's an interesting idea. I'll check with @seliopou.
y
On Sun, Nov 26, 2017 at 1:17 PM, Daniel Bünzli [email protected] wrote:
Also note sure exactly what your "reasons" are but jsonm is quite precise with location tracking for error reporting. If you don't really care about that maybe @seliopou https://github.com/seliopou's angstrom based json https://github.com/inhabitedtype/angstrom/blob/master/examples/rFC7159.ml decoder may be worth considering.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dbuenzli/jsonm/issues/10#issuecomment-347027681, or mute the thread https://github.com/notifications/unsubscribe-auth/AArqJq8v8hrDaMz-OlhUXA3Q8LCuwpkSks5s6atBgaJpZM4Qq2he .
Cool, if you end up benchmarking that aswell against jsonm I'm interested in hearing the results.
I'm curious, @yminsky have you tried writing parsers using angstrom in the end?
I was considering different parsers (including jsonm) and found this issue. We'd be interested in avoiding allocation of the json AST for performance reasons at Cryptosense as well so angstrom could prove useful for that.
The idea in the end would be to write a ppx to derive such json parsers/printers.
@seliopou wrote such a parser, though we haven't open sourced it yet. He can say more, and I think we'd be happy to release it.
