Hacker News new | past | comments | ask | show | jobs | submit login

Since you're in here, if I can recommend: sync.Pool with non-fixed-size objects is a source of many problems. https://wundergraph.com/blog/golang-sync-pool as a decent overview, and https://github.com/yarpc/yarpc-go/issues/2355 has been my recent plague.

If you browse around Go's stdlib use of sync.Pool, you'll see a variety of tiered pools with fixed sizes, and many drop anything over a large enough size (sometimes gigantic! as much as 16KB!): https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/...

It's a pretty well-established gotcha, sadly, and https://github.com/teivah/100-go-mistakes/blob/master/src/12... falls right into it.




Wish Go had introduced memory arenas. Most of the use cases for pools could have been cleanly solved by arenas.


Go has had experimental arena api since 1.22 or so


The experiment failed, though. It is dead at this point.


I think they removed arenas again.


Maybe I'm wrong, but when reading the first article, it seems like the entire thing exists mainly (not completely) because Go's GC isn't generational.


Maybe somewhat, but it's not hard to get pathologically bad GC behavior out of generational GCs either. Pools / manual memory management will always have some reasonable use cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: