Those numbers look similar to goccy. I used to use it in the past, even Kubernetes uses it as direct dependency, but the amount of issues have been stockpiling for quite some time so I no longer trust it.

So it seems both are operating at the edge of Go's capabilities.

Personally, I think JSON should be in Go's core and highly optimised simd c code and not in the Go's std library as standard Go code. As JSON is such an important part of the web nowadays, it deserves to be treated with more care.

Agreed. goccy has better performance most times but absolutely appalling worst-case performance which renders it unacceptable for many use cases - in my case even with trusted input it took effectively eternity to decode it. It's literally a quadratic worst case, what's the point of having a bunch of super clever optimisations if the big-O performance is that bad.

Sonic may be different but I'm feeling once bitten twice shy on "faster" JSON parsers at this point. A highly optimised SIMD version might be nice but the stdlib json package needs to work for everything out there, not just the cases the author decided to test on, and I'd be a lot more nervous about something like that being sufficiently well tested given the extra complexity.

What does "highly optimized" have to do with whether it's in the standard library? Highly-optimized cryptography is in the standard library.

Not to mention that Go is never going to put C code in the standard library for anything portable. It's all Go or assembly now.

It's amusing to see assembly considered more portable than C.

No, portable code is written in Go, not C. Platform specific code is written in ASM.

Which is the right approach, and one of the areas I actually appreciate the work of Go authors.

There is nothing special about C, other that its historical availability after UNIX's free beer came to be.

Any combination of high level + Assembly is enough.

Previously Go team has been vocal about sacrificing performance to keep stdlib idiomatic and readable. Guess the crypto packages are the exception because they are used heavily by Google internally and json and some others (like say image/jpeg which had crap performance last time i checked) are not.

Edit: See: https://go.dev/wiki/AssemblyPolicy

sonic uses a clang-generated ASM, built from C (transformed from normal clang-generated ASM to "weird" go ASM via python script)... I don't think this will be in standard library.

Go doesn't yet have native SIMD support, but it actually might in the future: https://github.com/golang/go/issues/73787

I think when it's introduced it might be worth discussing that again. Otherwise providing assembly for JSON of all packages seems like a huge maintenance burden for very little benefit for end users (since faster alternatives are readily available)

Interesting that the proposal is for low-level intrinsics as well as a non-processor-specific api: > Our plan is to take a two-level approach: Low-level architecture-specific API and intrinsics, and a high-level portable vector API. The low-level intrinsics will closely resemble the machine instructions (most intrinsics will compile to a single instruction), and will serve as building blocks for the high-level API.

> As JSON is such an important part of the web nowadays, it deserves to be treated with more care.

There is a case to be made here but Corba, SOAP and XML-RPC likely looked similarly sticky and eternal in the past

I hear you, but I am not aware of anyone that tried XMLHttpRequest.send('<s:Envelope xmlns:s...') or its '<methodCall>' friend from the browser. I think that's why they cited "of the web" and not "of RPC frameworks"

No, because that was server's job on the endpoint.

I don't recall either CORBA or SOAP ever seeing enough penetration to look "eternal" as mainstream tech goes (obviously, and especially with SOAP, there's still plenty of enterprise use). Unlike XML and JSON.

They surely were, for anyone doing enterprise during the 2000's.

We had no plans to change to something else.

I recall a lot of talk about CORBA in early 00s, but I don't think I've actually ever seen it used anywhere outside of Gnome.

By late 00s, even the talk was more along the lines of it being legacy tech.

Several Nokia Networks products were based on CORBA, running on HP-UX, in a mix of C++ and Perl.

Eventually migrated to Java EE, also taking advantage of CORBA compatibility.

Q3 is still in C++. Huawei also still supports CORBA.

Eternal or not, right now JSON is used everywhere which means the performance gains of a more optimized Stalin would be significant. Just because we don’t know if JSON is around in 10 years doesn’t mean we should settle for burning extra compute on it.

The fact that JSON is used so commonly for web stuff seems like an argument against wasting your time optimizing it. Network round trip is almost always going to dominate.

If you're pushing data around on disk where the serialization library is your bottleneck, pick a better format.

You’re assuming request-response round trip between each call to encode/decode. Streaming large objects/NDJSON would still have serialization bottleneck. (See elasticsearch/opensearch for a real life use case)

But in that case your last point still stands: pick a better format

There is no better human-readable format. I looked. The only alternative i considered was Amazon Ion but it proved to bring no additional value compared to json.

This is an interesting perversion of Amdahl's law.

Yes, if you are looking at a single request-response interaction over the Internet in isolation and observing against wall clock time, the time spent on JSON (de-)serialization (unless egregiously atrocious) will usually be insignificant.

But that's just one perspective. If we look at CPU time instead of wall clock time, the JSON may dominate over the network calls. Moreover, in a language like Go, which can easily handle tens to hundreds of thousands of parked green threads waiting for network activity, the time spent on JSON can actually be a significant factor in request throughput. Even "just" doubling RPS from 10k to 20k would mean using half as much energy (or half as much cloud compute spend etc.) per request.

Changing formats (esp to a low-overhead binary one) might yield better performance still, but it will also have costs, both in time spent making the change (which could take months) and adapting to it (new tools, new log formats, new training, etc.).

If you're optimizing for energy wasted serving your website you could stop sending 10 megs of garbage javascript on page load.

IIRC, sonic does JIT, has inline assembly (github says 41%), and it's huge. There's no way you can audit it. If you don't need to squeeze every cpu cycle out of your json parser (and most of us don't; go wouldn't be the first choice for such performance anyway), I'd stick with a simpler implementation.

It also seems to need 4x the memory

first of all, that doesn't exercise JSON v2 at all, afaict

second of all, sonic apparently uses unsafe to (unsafe-ly) cast byte slices to strings, which of course is gonna be faster than doing things correctly, but is also of course incomparable to doing things correctly

like almost all benchmark data posted to hn -- unsound, ignore

Just using the GOEXPERIMENT=jsonv2 compiler flag changes the underlying implementation if you don't change any code. You're still using the less correct and efficient API though.

And Sonic with its "cutting edge" optimization is still slower than std Json on arm64 with basic use cases. It shows that JIT, simd, low level code comes at cost of maintenance for all platform.

https://github.com/bytedance/sonic/issues/785