|
|
|
|
|
|
by timtadh
4058 days ago
|
|
|
Not a very useful article from the perspective of you are the point where you need to take some control over memory management in Go. The article spends a lot of time telling you should probably don't have that problem or you are not going to do any better than the Go. However, it is pretty easy to start proving you have that problem. Furthmore, you can make a real dent in the problem if you spend enough time working on it. I should probably not just complain but explain 1. How to prove via pprof and other tools that you have problems related to memory allocation or GC. 2. Some strategies for addressing that problem that don't involve writing an allocator. Using sync.Pool or a recycler pattern. Keeping allocations on the stack etc... 3. How to write a allocation interface in Go for allocating arbitrary objects. Aka emulating New and Make. 4. How to write a allocator backed by a memory mapped files. I have been working for a while in this space because of my academic research which involves frequent subgraph mining. That particular data mining problem is exponential and certain techniques can use a lot of memory. In order to scale my solution I have need to get the memory allocations under tight control. Sometimes I think I should just re-write in C++ or Rust but Go has provided me a lot of benefits from the concurrency angle so it isn't a win/win to move languages. Maybe I will write up all of this stuff at some point. It is a bit much for an HN comment. |
|
|
Maybe some information about how heap size and mutation rate affect GC would be interesting, as well as the future of the Go GC.
One interesting thing about Go is that if your objects contain no pointers, the Go GC does not have to scan them. So you can supposedly create huge slices of any type containing no pointers and the GC will have a much lower load on it.
There's a really good article from Dmitry Vyukov including memory related stuff here: https://software.intel.com/en-us/blogs/2014/05/10/debugging-...