Improvement suggestion: While reading the README, the JSON library comparison [1] it's confusing, at least to me. It uses symbols like: ○, and △ which are not obvious. I would rather use "yes/no" or the classic check/x (unicode chars, HN does not support them here) if you want to use symbols. I don't know what "△" even means, so I cannot suggest an alternative.
Another suggestion in the chart: it isn't obvious which line is about your project because it doesnt list the `goccy/` part. I would add that and move it to the top, out it and the standard in bold.
How does it handle de-serializing to structs with interface members? With encoding/json and ffjson, I had to write some code to handle that myself and add a type-tag member to my struct, which wasn't a deal-breaker, but if I could avoid that, I would like that very much.
I think it depends on the application. In many cases, encoding/json is fast enough and stable, but I think you can try to use a faster library if JSON encoding / decoding is performance critical on your application.
If you write off the "JSON", sure, there's a bajillion options. But that's not always possible or desirable. None of those bajillion options have the combination of support and mindshare that JSON has obtained, for better or worse.
That looks great, especially some of the unique optimisations. I gave it a nonscientific test run with a set of 1k different 2-4kb JSON encoded messages that we saw in our day to day traffic using the default Go benchmark library. Compared to easyjson (generated parser) goccy/go-json is unfortunately 20-25% slower and allocated four times the number of bytes.
Any chance that you will implement code generation like easyjson?
Are you unmarshaling to interface{}?
Have you tried commenting out the easyjson json.Un/Marshaler implementations? By default they wrap the easyjson code and add reflection overhead.
I had the same results when testing with a project that is already using easyjson, but after commenting out easyjson's json.Un/Marshaler impls I am seeing much improved performance using goccy/go-json.
Indeed. Thanks for the hint! While the allocations are still 2.5x, not by accident calling into easyjson makes goccy/go-json perform faster than easyjson with generated code by ~10%. That is some impressive result.
I find the circles, crosses and triangles on https://github.com/goccy/go-json#json-library-comparison hard to comprehend. I guess that circle means "yes", cross is "no" and triangle is "partial" or something. However that is really just based on context. (I guessed the symbols from what I thought the data should be)
I would suggest using words like "yes", "no" and "partial". They are short and clear. If you really want to do symbols I recommend using for yes, and still spelling out whatever triangle is supposed to mean.
My first thought was "yes", "no" and "ish" since the last one is a similar length to the first two.
My second thought was that that was probably just going to move the confusion to non-native english speakers.
Given a math background, ~~ for 'ish' is also tempting ... but while writing this out I've circled back around to "I can't think of anything better than partial".
The README is a treasure trove of information on go internals, thank you for writing all of that out. Fascinating to read what looks like your your thought process as you built this library, I always sort of thought README's should sometimes be a "diary of design decisions"
That being said, I'm not really at a point where json decoding is a bottleneck in any of the code I write, but will keep this in mind. Great job!
I tried to compare it with simdjson-go, but the interface of this library is very different from other libraries and it was difficult to compare. However, I think simdjson-go has the best decoder performance.
Very interesting read in the README. It's a bit scary, so I'm not sure I'd use this in a real program, but I learned some cool stuff reading the description!
Thank you for your feedback! In fact, it's understandable to be scared because it uses a lot of uncommon techniques. By growing this project, I would like to be able to use advanced techniques with peace of mind.
This library is available by simply replacing the import statement. It's more compatible and much faster than json-iterator/go.
Please give me your feedback ! Thanks !