Why does slog's `LogAttrs` allocate less than `Logger.Info` with key/value arguments?

## Two ways to say the same thing `log/slog` offers each line in two forms: ```go logger.Info("stage done", "shard", 7, "records", 1024) logger.LogAttrs(ctx, slog.LevelInfo, "stage done", slog.Int("shard", 7), slog.Int("records", 1024)) ``` They produce the same output. They do not cost the same, and the reason is entirely in the two signatures. ## What the variadic form costs `func (l *Logger) Info(msg string, args ...any)` has a `...any` parameter. At the call site the compiler builds a `[]any` and converts each argument into an interface value. An interface value is two words — a type descriptor and a data pointer — so a value that is not already pointer-shaped needs somewhere for that pointer to point. When the compiler cannot prove the value's lifetime ends in the frame, it allocates on the heap. Because `args` is handed to slog's internals, it generally does escape. So you pay for the slice, plus roughly one allocation for each non-pointer value: the `7`, the `1024`, and each key's string header. There is a second, smaller cost on the slog side. The alternating key/value convention has to be *decoded*: slog walks the slice two elements at a time, type-asserts the first of each pair to a `string`, and builds an `Attr` from it. That work is proportional to the number of arguments, and it happens on every record. ## What LogAttrs avoids `func (l *Logger) LogAttrs(ctx context.Context, level Level, msg string, attrs ...Attr)` takes a concrete type. A `slog.Attr` is a struct holding a `string` key and a `slog.Value`. `Value` is a small struct designed to carry the common kinds — string, int64, uint64, float64, bool, `time.Duration`, `time.Time` — in its own fields rather than in an `any`. So `slog.Int("shard", 7)` produces a value with no interface conversion and therefore no boxing allocation, and `slog.String("stage", name)` carries the string without heap-allocating a copy. The pairs are already formed, so there is no run-time decoding of a key/value convention and no chance of a mismatched dangling key. And `slog.Record` keeps a small number of attributes in an inline array before it has to reach for a heap slice, so a line with a few attributes often needs no slice allocation at all. Put together, a `LogAttrs` line with the built-in JSON handler commonly benchmarks at zero or one allocation per call, against a few for the variadic form. "Commonly" is doing real work in that sentence: the exact numbers depend on the handler, the number of attributes and the compiler version, which is why the honest answer ends with a benchmark rather than a figure. ## slog.Any is the exception `slog.Any(key, value)` takes an `any`, so it puts the boxing straight back: the value is converted to an interface exactly as it would be in the variadic form, and the handler then has to fall back on reflection or `encoding/json` to render something it has no typed path for. `slog.Any` is the right tool when the type genuinely is not known, and the wrong reflex when a typed constructor exists. ## Measuring it The diagnostic that settles this is a benchmark with allocation reporting: ``` go test -bench=. -benchmem ``` `-benchmem` adds two columns to the usual `ns/op`: `B/op`, bytes allocated per iteration, and `allocs/op`, the number of distinct allocations. Point both benchmarks at the same handler writing to `io.Discard` so you are comparing call forms and not I/O, and call `b.ReportAllocs()` if you would rather not depend on the flag. ## When it is worth it The variadic form is shorter and reads better, and outside a hot path the difference is invisible next to the cost of formatting and writing the line. Reach for `LogAttrs` where the call runs per record in a stream, per row in a batch job, or inside a library that other people will drop into their own hot loops. Rewriting every log line in a service to `LogAttrs` buys nothing measurable and costs readability on every cold path you touch.