Replies: 3 comments 2 replies
-
Beta Was this translation helpful? Give feedback.
1 reply
-
@hanjk1234 could you provide the json data and I used mocked data and my output is
|
Beta Was this translation helpful? Give feedback.
1 reply
-
metric_data.json go version 芯片: Apple M4 Pro |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I've written a benchmark to compare MessagePack, stdlib Json, Sonic Json and Protobuf to decide on a codec for a project, but I'm consistently getting unexpected results for Sonic vs. Go Json.
The decoding is faster than stdlib, just as expected. Advertised is 3,2x faster, I'm getting 3,2x faster, up to 3,9x faster.
But the encoding is weirdly slow. Go Json is 2x faster than sonic.
I thought it might be because the objects aren't really that complex, but the README says that:
So I would have thought that includes my scenario as well.
For the single benchmark I'm en/decoding the following item:
The multiple one is using an
type Items []Item
with similar values to the item above.Here are the benchmark results (along with the proto and msgpack ones)
bytes/obj
is a metric I added to compare the resulting size.Just to rule out the issue is with my setup, my struct or my code, I've also added Go Json and Json Iterator to the benchmark, as in Sonic' README.
If needed, I can add the benchmark code, but it's the exact same function for all (expect proto for obvious reasons), just with the respective (Un)Marshal function passed in, so basically
encode(b, sonic.Marshal)
, etc.Does anyone has an idea why the encoding is so much faster in the stdlib Json, instead of Sonic like how I expected it to be?
Beta Was this translation helpful? Give feedback.
All reactions