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

[Michał Muskała]

For testing JSON parsers/encoders I recommend https://github.com/nst/JSONTestSuite

Michał.
On 28 Jun 2018, 10:17 +0200, zxq9@REDACTED, wrote:
> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180628/03b77f72/attachment.htm>