When does a call to a Go `...any` variadic helper allocate, and how would you keep that off a hot path?

## Two costs that get confused with each other When someone says "variadic calls allocate", they are usually running together two separate mechanisms, and telling them apart is the whole senior answer. **Materialising the slice.** A call site that lists loose arguments — `render(tmpl, r.Name, r.Locale)` — needs a backing array to put those arguments in. The compiler emits code to build it. That happens once per call, at the call site, and it happens whether the parameter is `...int` or `...any`. **Forwarding an existing slice.** A wrapper whose own parameter is `args ...any` and which calls `inner(tmpl, args...)` builds nothing. The spread form passes the header it already has. Add five wrapper layers and you have added five function calls, not five slices. This surprises people who assume each layer "re-packs" the arguments. ```go func render(tmpl string, args ...any) string { return fmt.Sprintf(tmpl, args...) } // this call site materializes a []any on every iteration for i, r := range recipients { out[i] = render(greeting, r.Name, r.Locale) } // the wrapper forwards the slice it already has; nothing new is built func renderFor(tmpl string, args ...any) string { return render(tmpl, args...) } ``` ## Stack or heap is an escape-analysis question Materialising the slice does not automatically mean a heap allocation. Escape analysis is a compile-time decision: the compiler heap-allocates a value only when it cannot prove the value's lifetime ends with the frame. If the variadic slice is used and dropped inside the callee, it can live on the stack and cost nothing an allocation counter would see. If the callee stores it somewhere, returns something derived from it that keeps it alive, or hands it to code the compiler cannot see through, the slice escapes and you pay. That is why the honest answer to "does this allocate" is *measure it*, not *yes* or *no*. The measurement is a benchmark run with `-benchmem`, which reports bytes and allocations per operation alongside the timing: ``` go test -bench=Compose -benchmem ./composer ``` Run it, change one thing, run it again. A composer whose allocations per operation scale with the recipient count is telling you the cost is in the per-recipient loop, and the two candidates inside that loop are the slice the call site builds and whatever the callee does with it. ## Fixes that do not change behaviour **A fixed-arity variant.** Offer `render1(tmpl string, a any)` beside `render(tmpl string, args ...any)`, and let the hot one-argument path use it. No slice is built at all. The cost is a wider API surface: two spellings of the same operation that every reader must now choose between. Justify it with a benchmark or do not do it. **Hoist the work out of the loop.** Often the variadic call is not the real cost — the formatting behind it is, and it is being redone per recipient for a message whose shape never changes. Precomputing the parts that do not vary per recipient removes far more than the slice ever did. **Write into a caller-supplied destination.** Handing the callee somewhere to write, rather than having it return freshly built values, moves the allocation decision to the caller, who can reuse across iterations. ## The reuse trap The tempting fourth fix is to build one `[]any` before the loop and spread it every iteration, overwriting the elements each time. Sometimes that is correct and sometimes it is a bug you will spend an afternoon on. Because the spread hands the callee **your** slice, a callee that retains it — or retains a value derived from it — keeps looking at storage you are about to overwrite on the next iteration. Reuse is safe only for a callee you own, that you know is synchronous, and that you know does not keep a reference. Against a callee you do not control, the saved allocation is not worth the aliasing risk. ## The order to work in Measure with `-benchmem`; identify whether allocations scale with call count or with input size; check whether the cost is the slice the call site builds or what the callee retains; change one thing; measure again. Reaching for a fixed-arity API before that sequence is how a codebase acquires two entry points for every helper and no measurable improvement.