HarHarVeryFunny 2026-02-27 18:21 UTC link

This article is about Go, but I wonder how many C/C++ developers realize that you've always had the ability to allocate on the stack using alloca() rather than malloc().

Of course use cases are limited (variable length buffers/strings, etc) since the lifetime of anything on the stack has to match the lifetime of the stack frame (i.e the calling function), but it's super fast since it's just bumping up the stack pointer.

bertylicious 2026-02-27 18:34 UTC link

Nice! That's (seems) so simple yet also so very effective. Shouldn't other memory-managed languages be able to profit from this as well?

nasretdinov 2026-02-27 18:41 UTC link

Nice to see common and natural patterns to have their performance improved. Theoretically appending to a slice would be possible to handle with just stack growth, but that would require having large gaps between goroutine stacks and mapping them lazily upon access instead of moving goroutines to the new contiguous blocks as it's implemented right now. But given how many questionable changes it requires from runtime it's certainly not going to happen :)

anematode 2026-02-27 18:45 UTC link

Awesome stuff! Does Go have profile-guided optimization? I'm wondering whether a profile could hint to the compiler how large to make the pre-reserved stack space.

zabzonk 2026-02-27 18:53 UTC link

alloca() is not part of the C++ standard, and I can't imagine how it could used safely in a C++ environment

mwkaufma 2026-02-27 19:08 UTC link

If I had a nickel for every article about avoiding implicit boxing in gc-heap languages...

lstodd 2026-02-27 19:39 UTC link

I read that as "Allocating on the Slack" and immediately came up with three ways how to do that.

csjh 2026-02-27 20:34 UTC link

Optimizations like these are so cool. I love seeing higher level languages take advantage of their high level-ness

OptionOfT 2026-02-27 21:14 UTC link

> ... > On the third loop iteration, the backing store of size 2 is full. append again has to allocate a new backing store, this time of size 4. The old backing store of size 2 is now garbage.

Correct me if I'm wrong, but isn't this a worst-case scenario? realloc can, iirc, extend in place. Your original pointer is still invalid then, but no copy is needed then.

Unless I'm missing something?

Equally, what happens to the ordering of variables on the stack? Is this new one pushed as the last one? Or is there space kept open?

E.g.:

    var tasks []task
    var other_var int

matthewaveryusa 2026-02-27 22:10 UTC link

It's kind of like the small string optimization you see in C++[1] where all the string metadata to account for heap pointer, size and capacity is union'ed with char*. Getting the stack allocation doesn't costs extra memory, but does cost a bit check. Not sure if slices in go use the same method. 32 bytes is a lot so maybe they fattened slice representations a bit to get a bit more bang for your buck?

[1] https://github.com/elliotgoodrich/SSO-23

up2isomorphism 2026-02-27 23:32 UTC link

It is actually a bad design when compiler go this far into a micro optimization but assume it understands the context so it can make decisions for you.

heavenlyhash 2026-02-28 12:58 UTC link

I want to like this, and it's directionally good work...

But it's hard to see this as very useful unless we also start to see some increases in legibility, and ways to make sure these optimizations are being used (and that textually minor changes don't cause non-obvious performance regressions).

I've written a lot of golang code that was benchmarked to shreds, and in which we absolutely cared about stack-vs-heap allocations because they were crucial to overall performance. I've spent a lot of time pouring over assembler dumps, because grepping those for indications of new object creation was sometimes clearer (and certainly more definitive) than trying to infer it from the source code level. The one thing I've learned from this?

It's very, very easy for all those efforts to come to naught if the rules change slightly.

And it's very, very, VERY easy for a co-maintainer on a project to stroll in and make seemingly textually trivial changes that have outsized impacts. (I'm looking at inliner thresholds, specifically. Hoo boy.)

The best balm we have for this right now is writing benchmarks and making sure they report zero allocs. (Or unit tests using the runtime memstats harness; potato potato.) But that is a very fragile balm, and relatively complex to maintain, and (if DX is considered) is not textually local to the code in question -- which means someone changing the code can easily miss the criticality of a section (until the tests yell at them, at least).

I really yearn for some markup that can say "I expect this code to contain zero heap allocations; please flunk the compile if that is not the case".

ozgrakkurt 2026-02-27 18:25 UTC link

This is more of a patch/hack solution as far as I can understand.

You can just as well pass a heap allocated buffer + size around and allocate by incrementing/decrementing size.

Or even better use something like zig's FixedSizeAllocator.

Correct me if I am wrong please

rwmj 2026-02-27 18:31 UTC link

Most C compilers let you use variable length arrays on the stack. However they're problematic and mature code bases usually disable this (-Werror -Wvla) because if the size is derived from user input then it's exploitable.

spacechild1 2026-02-27 18:36 UTC link

alloca() is super useful, but it's also quite dangerous because you can easily overflow the stack.

The obvious issue is that you can't know how much space is left on the stack, so you basically have to guess and pick an arbitrary "safe" size limit. This gets even more tricky when functions may be called recursively.

The more subtle issue is that the stack memory returned by alloca() has function scope and therefore you must never call it directly in a loop.

I use alloca() on a regular basis, but I have to say there are safer and better alternatives, depending on the particular use case: arena/frame allocators, threadlocal pseudo-stacks, static vectors, small vector optimizations, etc.

anematode 2026-02-27 18:44 UTC link

If you're not doing recursion, I prefer using an appropriately sized thread_local buffer in this scenario. Saves you the allocation and does the bookkeeping of having one per thread

ivanjermakov 2026-02-27 18:54 UTC link

Having big stack frames is bad for cache locality. Stack is not something magical, it's mapped to the same physical memory as heap and needs to be loaded. Pretty sure such optimization would reduce performance in most cases.

tptacek 2026-02-27 19:00 UTC link

Yep. `go build -pgo=foo.pprof`

https://go.dev/doc/pgo

lionkor 2026-02-27 19:26 UTC link

C# has `stackalloc`

adonovan 2026-02-27 20:14 UTC link

...you would have the same balance as before, because this is not an article about implicit boxing. ;-)

dzdt 2026-02-27 20:23 UTC link

For purely historical reasons the C/C++ stack is "small" with exactly how small being outside of programmer control. So you have to avoid using the stack even if it would be the better solution. Otherwise you risk your program crashing/failing with stack overflow errors.

fsckboy 2026-02-27 22:02 UTC link

you can do this in C, you just need to let its low level-ness be at the same level as everything else you do, just a setjmp longerjmp

kbolino 2026-02-27 22:13 UTC link

The ability to grow without copying is already part of how slices work. Every slice is really a 3-word tuple of pointer, length, and capacity. If not explicitly set with make, the capacity property defaults to a value that fills out the size class of the allocation. It just so happens that, in this case, the size of the Task type doesn't allow for more than 1 value to fit in the smallest allocation. If you were to do this with a []byte or []int32 etc., you would see that the capacity doesn't necessarily start at 1: https://go.dev/play/p/G5cifdChGIZ

KolmogorovComp 2026-02-27 23:58 UTC link

It’s a very well known pattern, as someone else mentioned it’s used in CPP in smallstring, Rust smallvec, C usually hand rolled etc.

AdieuToLogic 2026-02-28 00:48 UTC link

> It's kind of like the small string optimization you see in C++ ...

Agreed. These types of optimizations can yield significant benefits and are often employed in language standard libraries. For example, the Scala standard library employs an analogous optimization in their Set[0] collection type.

0 - https://github.com/scala/scala3/blob/88438e2c6e6204e12666067...

joshsegall 2026-02-28 01:17 UTC link

Agreed. There's quite a bit of room for optimization if your language design allows for it. Plus you have flexibility to make different tradeoffs as computer architectures and the cost of various operations change over time.

direwolf20 2026-02-28 09:49 UTC link

[]task is a pointer to a range of elements. TFA says if you initialize it to point to a new array of 10 elements, that array of 10 elements may be stack–allocated. If you allocate another array dynamically, that one won't be.

Editorial Channel

What the content says

Structural Channel

What the site does