[HN Gopher] Golang optimizations for high-volume services
       ___________________________________________________________________
        
       Golang optimizations for high-volume services
        
       Author : der_gopher
       Score  : 33 points
       Date   : 2025-12-08 11:49 UTC (3 days ago)
        
 (HTM) web link (packagemain.tech)
 (TXT) w3m dump (packagemain.tech)
        
       | jftuga wrote:
       | I'd be curious to know transactions per second (or other metrics)
       | before and after the suggested changes.
        
         | theHurzzen wrote:
         | Indeed. The post can be more interesting with proper metrics to
         | backup the impact of each change.
        
       | ad_hockey wrote:
       | 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
        
         | PhilippGille wrote:
         | There's various alternatives. For example:
         | 
         | - https://github.com/goccy/go-json
         | 
         | - https://github.com/bytedance/sonic
        
       | vrnvu wrote:
       | My first thought: Controlling allocations and minding
       | constraints... honestly, that's engineering stuff all services
       | should care about. Not only "high-volume" services.
        
         | ashf023 wrote:
         | 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.
        
       | aranw wrote:
       | 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
        
       | Ameo wrote:
       | 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).
        
         | tptacek wrote:
         | _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
        
       ___________________________________________________________________
       (page generated 2025-12-11 23:01 UTC)