ffjson VS easyjson

ffjson failed to compile, last commit 2019

Compile time means you catch issues at... well compile time. It also means that the code is optimized. You can look at the performance different between encoding/json and easyjson for why you may desire that.

easyjson produced an empty file

There is https://github.com/mailru/easyjson out there if you are absolutely sure that serialization is the bottleneck. Otherwise I'd go for stdlib.

https://github.com/mailru/easyjson fast JSON (de)serializer which go generates code instead of using reflect at runtime.

If you know the schema of the JSON ahead of time and you need to parse the whole object, I would recommend https://github.com/mailru/easyjson as that will likely give you the fastest result. This works in almost all use cases, and easy to use features such as string interning can save you a lot of time on memory allocation if you parse a lot of JSON objects with identical values.

What to use Easyjson is about the top of the pack and it's straightforward. The downside of efficient tools is that they use code generation to create the code required to turn your structs into json to minimise allocations. This is a manual build step which is annoying. Interestingly json-iterator also uses reflection but it's significantly faster. I suspect black magic.

I'm looking for something similar to https://github.com/mailru/easyjson where one can generate a concrete JSON parser for some types.

Бібліотека easyjson теж для серіалізації працює через додатковий код замість використання рефлексії. Але після внесення в easyjson одної з оптимізацій, час від часу почали отримувати зламаний JSON, ось приклад тесту який покаже помилку.