
New JSON parser for Go: up to 9x faster than `encoding/json` - LeonidBugaev
https://github.com/buger/jsonparser
======
zimbatm
This could be useful if only a small subset of the JSON content is needed. It
would be interesting to see how it compares when the number of fields grow.

One missing for comparison:
[https://github.com/ugorji/go/](https://github.com/ugorji/go/)

~~~
lobster_johnson
go-codec is nice, but in my testing I found it to be slower than Go's
encoding/json.

~~~
zimbatm
with the `go generate` version as well ?

~~~
lobster_johnson
That I don't know — probably not. Never used it, since my performance issues
have always been with raw map[string]interface{} data.

------
LeonidBugaev
I'm the author.

Happy to answer any questions, hope you like it!

~~~
lobster_johnson
This is very useful, thanks! Go's slow JSON parser is annoying.

My only criticism is that returning 4 values from a function is not very
ergonomic, especially since most of the return values aren't needed in many
cases.

It would have been better and more idiomatic to return a struct.
Alternatively, let it take a pointer to a struct — this would let you avoid
memory allocation in loops (though in theory Go should be able to optimize a
struct return, too; anyone know?).

~~~
LeonidBugaev
Good point, i will think how to make it work.

------
giovannibajo1
Did you run any compliance test? I don't mind a fast parser, but I fear a fast
parser that breaks on unusual-but-standard input...

~~~
bazzargh
It's definitely _not_ compliant. I just read the code, there's no support for
escapes in strings, except for skipping over escaped double quotes to find the
string end. This applies to any string, so it also won't correctly match keys
that contain escapes. (hence the small number of allocations)

Edited to add: this has its uses, if you know that's all you need. Long ago I
wrote a similar xml parser for a project because we had control over the xml
being produced, and the garbage overhead from element names was killing us
with Xerces; I didn't bother implementing things like DTD support, because
YAGNI.

------
bebna
Why should anyone want to use it? It only reads and even with that it doesn't
do everything you expect from a go json lib. It is basically nothing more than
a tokenizer.

~~~
LeonidBugaev
There is lot of tasks when you need only to read data, 3-rd party API, log
processing and lot more. For sure this lib not for everyone, but if you care
about performance, and especially memory consumption, this could make sense.

Can you a bit clarify about your expectations?

