←back to thread

480 points jedeusus | 1 comments | | HN request time: 0s | source
Show context
jensneuse ◴[] 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 ◴[] 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 ◴[] No.43544988[source]
That's just not true. Pool contents are GCed after two cycles if unused.
replies(1): >>43547338 #
nopurpose ◴[] 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. ahmedtd ◴[] No.43550287[source]
From the sync.Pool documentation:

> If the Pool holds the only reference when this happens, the item might be deallocated.

Conceptually, the pool is holding a weak pointer to the items inside it. The GC is free to clean them up if it wants to, when it gets triggered.