3 ms·
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 typ
by ozten 7y 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.
- sascha_sl 7y agoGo has a tool for this job. https://golang.org/pkg/sync/#Pool https://golang.org/pkg/sync/#Pool
- jhgg 7y agochecked 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.
- sascha_sl 7y agoWell, 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.