Hacker News new | ask | show | jobs
by ozten 2329 days ago
Yes and no. You can get very clever by pre-allocating memory and ensuring it is never garbage collected, but at that point you're opening yourself up to new types of bugs and other performance issues as you try to scale your hack.

As you fight your language, you're GC avoidance system will become larger and larger. At some point you might re-evaluate your latency requirements, your architecture, and which are the right tools for the job.
1 comments
sascha_sl 2329 days ago
Go has a tool for this job.

https://golang.org/pkg/sync/#Pool

link
jhgg 2329 days ago
checked in objects in a sync pool gets cleaned up on GC. It used to clean the whole pool, but now I think it does half each GC cycle. If you want to say "objects checked in should live here forever and not free themselves unless I want them to" sync pool is not the tool for the job.
link
sascha_sl 2328 days ago
Well, it's a start. In fact the existing interface lends itself really well to a rolling window on-demand (de)allocator, especially with that New function you can supply.

Just pool could've mitigated your problem at least partially, is what I'm saying.

link