[erlang-questions] New project: ZJ - A tiny JSON encoder/decoder

[zxq9@REDACTED]

On 2018年6月28日木曜日 9時46分10秒 JST you wrote:
> Hi Craig,
> 
> The lib looks interesting, I would like to try it on my projects.
> 
> Few related questions:
> 1) Do you plan to add tests later on?
> 2) What do you think about publishing it on hex.pm, so it's easier
> to control releases (for those who are using it), maybe rebar3/erlang.mk
> can be quite helpful here?
> 3) Finally, the performance, did you have a chance to make some comparisons?

Hi, Oleg!

1- I fuzzed it by running real-world JSON through it, but am not convinced
of the utility of hand-written tests considering how narrow the actual
spec is compared to the variety of real-world illegal JSON out there. I
think the best way to *really* approach testing would be to write a script
that would evaluate its performance against either a bulk dataset stored
for that purpose or (much better) use PropEr.

I'm open to that, but don't have the time right now. It works for my cases
exactly as I intended, but I'm certainly open to contributions.

I fully realize my position is heretical.


2- If someone wants to push it to hex.pm that would be swell! I don't use
hex.pm in any projects at the moment, so it is a very low priority. Again,
more of a time issue for me than anything. My "extra" time budget wound up
getting spent on making sure the docs came out properly.

Same as #1, I'm open to that and would love to see it packaged for others
to use in a more simple way -- but it isn't a personal priority for me at
the moment. It will, however, be part of Zomp's default FOSS repository
once I get around to releasing that (so will JSX).


3- The only function I benchmarked formally was decode/1. It performed
about 5% (+/- 10) faster than JSX decode/1 -- so for all practical
purposes is the same. The *size* of the output of decode/1 is larger than
JSX when dealing with strings because decode/1 returns strings-as-strings,
not binaries. This is better for some kinds of manipulation, but isn't
very compact.

binary_decode/1 almost certainly performs a little slower than decode/1
because I didn't implement that in a particularly efficient way. I can
improve it to a comparable speed if that becomes necessary, though.
Anyway, this has not been benchmarked formally, just poked at with
timer:tc/1 a few times (but that isn't a particularly reliable way to
benchmark things).

I have not benchmarked encode/1 or binary_encode/1 at all, but would be
very surprised if they are meaningfully slower than JSX as the approach
taken is very similar -- the mapping between JSON <=> Erlang types being
the important difference.


Nice to hear from you!

-Craig