I've been thinking about trying an alternative JSON library, but interested to hear opinions on whether jsoniter is still recommended. There are 208 open issues on the repo, and a question about whether it's still maintained[1]
Would particularly like to know if anyone has done a performance comparison with the new API coming in the stdlib[2], which feels like a better bet. That blog says:
The Marshal performance of v2 is roughly at parity with v1. Sometimes it is slightly faster, but other times it is slightly slower. The Unmarshal performance of v2 is significantly faster than v1, with benchmarks demonstrating improvements of up to 10x.
I'd be curious to know transactions per second (or other metrics) before and after the suggested changes.
Indeed. The post can be more interesting with proper metrics to backup the impact of each change.
I'm currently working on a project that is using an OpenAPI library that decided to use a non-standard JSON encoder. The developer experience definitely suffers when you can't use common encoding/json patterns in your own code. Simple operations become unnecessarily awkward
Interesting tips, looking into Go perf recently also. However making sure postgres wal log does not grow seems like putting an unnecessary constraint on things and then defeating it
My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.
I'm definitely in favor of not pessimizing code and assuming you can just hotspot optimize later, but I would say to avoid reusing objects and using sync.pool if it's really not necessary. Go doesn't provide any protections around this, so it does increase the chance of bugs, even if it's not too difficult to do right.
What are the options? Repeated allocations are a huge performance sink.
Was curious to read this, but then the massive full-page ugly-on-purpose AI-generated NFT-looking banner image at the top of the page turned my stomach to the point where there's no way I'd even consider it - even if the article isn't AI-generated (which it probably is).
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
I've been thinking about trying an alternative JSON library, but interested to hear opinions on whether jsoniter is still recommended. There are 208 open issues on the repo, and a question about whether it's still maintained[1]
Would particularly like to know if anyone has done a performance comparison with the new API coming in the stdlib[2], which feels like a better bet. That blog says:
The Marshal performance of v2 is roughly at parity with v1. Sometimes it is slightly faster, but other times it is slightly slower. The Unmarshal performance of v2 is significantly faster than v1, with benchmarks demonstrating improvements of up to 10x.
[1] https://github.com/json-iterator/go/issues/706
[2] https://go.dev/blog/jsonv2-exp
There's various alternatives. For example:
- https://github.com/goccy/go-json
- https://github.com/bytedance/sonic
I'd be curious to know transactions per second (or other metrics) before and after the suggested changes.
Indeed. The post can be more interesting with proper metrics to backup the impact of each change.
I'm currently working on a project that is using an OpenAPI library that decided to use a non-standard JSON encoder. The developer experience definitely suffers when you can't use common encoding/json patterns in your own code. Simple operations become unnecessarily awkward
Interesting tips, looking into Go perf recently also. However making sure postgres wal log does not grow seems like putting an unnecessary constraint on things and then defeating it
My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.
I'm definitely in favor of not pessimizing code and assuming you can just hotspot optimize later, but I would say to avoid reusing objects and using sync.pool if it's really not necessary. Go doesn't provide any protections around this, so it does increase the chance of bugs, even if it's not too difficult to do right.
What are the options? Repeated allocations are a huge performance sink.
Was curious to read this, but then the massive full-page ugly-on-purpose AI-generated NFT-looking banner image at the top of the page turned my stomach to the point where there's no way I'd even consider it - even if the article isn't AI-generated (which it probably is).
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html