Earlier quoted context omitted.
That's ... not helpful. I already profile and profiling indicates that allocations are slow and sweeps are fast. Go's optimization for this is escape analysis which is a best-effort attempt to put things on the stack. Because the stack analysis is naive (which isn't necessarily a bad thing), it means lots of things are still allocated on the heap, and those are the allocations I'm referring to.
The bigger issue is usually stack vs heap allocation and it’s hard to reason about that. But the good news is that unlike a JIT system you can actually pretest golang escape analysis. Look at the -m gcflag to see what is escaping, then see if that is where the allocation hotspot is. If so see if you can get the escape to happen where you want. Otherwise you need to go no allocation. Notice that go actually gets _wors…
Re: Practices for writing high-performance Go
#101.NET has the ability to allocate on the stack, using `stackalloc` - does Go have a similar feature?