←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 1 comments | 31 Mar 25 20:29 UTC | HN request time: 0.212s | source
Show context
jensneuse ◴[31 Mar 25 23:06 UTC] No.43540964[source]▶
You can often fool yourself by using sync.Pool. pprof looks great because no allocs in benchmarks but memory usage goes through the roof. It's important to measure real world benefits, if any, and not just synthetic benchmarks.
replies(2): >>43541261 #>>43543697 #
nopurpose ◴[01 Apr 25 07:04 UTC] No.43543697[source]▶
also no one GCs sync.Pool. After a spike in utilization, live with increased memory usage until program restart.
replies(1): >>43544988 #
ncruces ◴[01 Apr 25 10:12 UTC] No.43544988[source]▶
That's just not true. Pool contents are GCed after two cycles if unused.
replies(1): >>43547338 #
nopurpose ◴[01 Apr 25 14:41 UTC] No.43547338[source]▶
What do you mean? Pool content can't be GCed , because there are references to it: pool itself.

What people do is what this article suggested, pool.Get/pool.Put, which makes it only grow in size even if load profile changes. App literally accumulated now unwanted garbage in pool and no app I have seen made and attempt to GC it.

replies(4): >>43549772 #>>43549789 #>>43550287 #>>43552731 #
1. ashf023 ◴[01 Apr 25 18:07 UTC] No.43549772[source]▶
sync.Pool uses weak references for this purpose. The pool does delay GC, and if your pooled objects have pointers, those are real and can be a problem. If your app never decreases the pool size, you've probably reached a stable equilibrium with usage, or your usage fits a pattern that GC has trouble with. If Go truly cannot GC your pooled objects, you probably have a memory leak. E.g. if you have Nodes in a graph with pointers to each other in the pool, and some root pointer to anything in the pool, that's a memory leak