Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A pool allocator could have reduced the number of existing allocations (1 big one instead of many small ones), making those spikes less significant. (But that depends on how Go handles interior pointers and GC, so I'm not sure.)


Allocations weren't the problem. It was the fact that, every 2 minutes, the GC would trigger because of an arbitrary decision by the Go team and scan their entire heap, find little to nothing to deallocate, then go on its merry way.


It has to track interior pointers. The problem for them seems to be the mark phase, where the GC has to track down all the pointers either way.




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

Search: