Optimizing Heap Allocations in Go: A Case Study(dolthub.com)
dolthub.com
Optimizing Heap Allocations in Go: A Case Study
https://www.dolthub.com/blog/2025-04-18-optimizing-heap-allocations/
11 comments
In general, it is a win, since it lets you code faster and 80-90% the performance doesn't matter. Over time, you learn generally what leads to heap allocs and what doesn't. In rare hot spot, using -m will show you the allocations and you can optimize.
I would generally agree. It's good enough performance for most applications. For those that it isn't fast enough for (even with optimizations like these), it still allows for rapid prototyping to arrive at that conclusion.
I think same applies to any GC language. Ride is fun until GC starts either taking too much time, too much memory or taking too much of CPU.
At least you have the tools to understand where things get allocated.
> It's possible that this is a compiler bug. It's also possible that there's some fringe case where the reference actually can escape via that method call, and the compiler doesn't have enough context to rule it out.
Here's an example, I think: suppose the method spawns a new goroutine that contains a reference to `chunkStore`. This goroutine can outlive the `ReadBytes` function call, and thus Go has to heap allocate the thing being referenced.
In general, this kind of example makes me suspect that Go's escape analysis algorithm treats any method call as a black box and heap allocates anything being passed to it by reference.
Here's an example, I think: suppose the method spawns a new goroutine that contains a reference to `chunkStore`. This goroutine can outlive the `ReadBytes` function call, and thus Go has to heap allocate the thing being referenced.
In general, this kind of example makes me suspect that Go's escape analysis algorithm treats any method call as a black box and heap allocates anything being passed to it by reference.
I had an attempt to improve performance of memory allocation with the use of arenas in Go and I chose freelist datastructure[1]
It almost doesn't use unsafe except one line to cast pointer types. I measured practical performance boost with "container/list" implementation hooked to my allocator. All in all it performs 2-5 times faster or up to 10 times faster if we can get rid[2] of any and allocations implied by the use of it.
All in all, heap allocations can be not that bad at all if you approach them from another angle.
[1]: https://github.com/Snawoot/freelist
[2]: https://github.com/Snawoot/list
It almost doesn't use unsafe except one line to cast pointer types. I measured practical performance boost with "container/list" implementation hooked to my allocator. All in all it performs 2-5 times faster or up to 10 times faster if we can get rid[2] of any and allocations implied by the use of it.
All in all, heap allocations can be not that bad at all if you approach them from another angle.
[1]: https://github.com/Snawoot/freelist
[2]: https://github.com/Snawoot/list
I wonder if the reason the escape analysis fails could be that, for small enough types, the concrete value is directly inlined inside the interface value, instead of the latter being "a smart pointer" as the author said. So when the compiler needs to take a reference to the concrete value in `vs.chunkStore`, that ends up as an internal pointer inside the `vs` allocation, requiring it to be on the heap.
Either that or the escape analysis just isn't smart enough; taking a pointer to an internal component of an interface value seems like a bit of a stretch.
Either that or the escape analysis just isn't smart enough; taking a pointer to an internal component of an interface value seems like a bit of a stretch.
This is one of the best and worst aspects with Go. Anyone can write pretty performant code without having to understand the underlying memory model. If you get to the point where you are trying to optimize at this level, the benefits of using a more approachable language start to fall apart and you spend more time chasing implementation details.