Golang optimizations for high‑volume services • Hacker News Board

Re: Golang optimizations for high‑volume services

#11

Post by Yokohiii » Fri, Dec 12, 2025, 2:33 AM UTC

ashf023 wrote: post #5

vrnvu wrote: post #4

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.

Re: Golang optimizations for high‑volume services

#12

Post by foobarkey » Fri, Dec 12, 2025, 5:12 PM UTC

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

Re: Golang optimizations for high‑volume services

#13

Post by ashf023 » Mon, Dec 15, 2025, 8:18 PM UTC

Yokohiii wrote: post #11

ashf023 wrote: post #5

Earlier quoted context omitted.

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.

I mean, do it if it's worth it. But the parent seemed to imply everyone should be doing this kind of thing. Engineering is about tradeoffs, and sometimes the best tradeoff is to keep it simple.

Re: Golang optimizations for high‑volume services

#14

Post by Yokohiii » Tue, Dec 16, 2025, 5:25 AM UTC

ashf023 wrote: post #13

Yokohiii wrote: post #11

Earlier quoted context omitted.

What are the options? Repeated allocations are a huge performance sink.

I mean, do it if it's worth it. But the parent seemed to imply everyone should be doing this kind of thing. Engineering is about tradeoffs, and sometimes the best tradeoff is to keep it simple.

Your initial judgement of using sync.Pool is quite overboard. The average go dev would wind up goroutines without much thought and pull in mutexes to avoid trouble. That's a hard thing to manage, using sync.Pool is comparatively easy.

For me it looks like the general sentiment is that go enabled concurrency, which should be leveraged, it also did simplify memory management, which should be ignored. But memory management has an direct impact on latency and throughput, to simply ignore it is like enabling concurrency just because someone said it's cool.