←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 1 comments | 31 Mar 25 20:29 UTC | HN request time: 0.254s | source
Show context
donatj ◴[01 Apr 25 11:15 UTC] No.43545402[source]▶
Unpopular opinion maybe, but sync.Pool is so sharp, dangerous and leaky that I'd avoid using it unless it's your absolute last option. And even then, maybe consider a second server first.
replies(2): >>43547899 #>>43550552 #
1. nasretdinov ◴[01 Apr 25 19:33 UTC] No.43550552[source]▶
I think in general people understand that sync.Pool introduces essentially an equivalent of unitialised memory (since objects aren't required to be cleaned up before returning them to the pool), and mostly use it for something like []byte, slicing it like buf[0:0] to avoid accidentally reading someone else's memory.

But the instrument itself is really sharp and is indeed kind of last resort