A Go pipeline stage logging with slog allocates six times per record at 40k records/s. Where do you look, and what do you change first?

## Attribute before you optimise Six allocations per record is a number, not a diagnosis. Before changing code, establish that the log call is the source. The cheap way is a pair of benchmarks over a realistic record, both pointed at the same handler writing to `io.Discard` so the comparison is about the code and not about I/O: ``` go test -bench=Stage -benchmem ``` Run the stage with the log call and again with it removed; `-benchmem` prints `B/op` and `allocs/op`, and the difference between the two rows is what the logging actually costs. This matters because a transform that decodes JSON or grows a slice can easily out-allocate its own log line, and rewriting the logging then buys nothing. ## Then work outward from the call site **1. Move the constant attributes off the hot path.** Fields like the stage name, the shard, the build version and the input topic do not change per record. Bind them once with `Logger.With`, which calls the handler's `WithAttrs`; the built-in text and JSON handlers serialise those attributes at that moment and copy the finished bytes into every later record. Build the derived logger where the stage starts, never inside the loop — a `With` per record costs more than the inlined fields it replaces. **2. Change the call form for what remains.** `logger.Info("enriched", "bytes", n, "id", id)` builds a `[]any`, boxes each non-pointer value into an interface, and makes slog decode the alternating pairs at run time. `logger.LogAttrs(ctx, slog.LevelInfo, "enriched", slog.Int("bytes", n), slog.String("id", id))` passes typed `slog.Attr` values whose `slog.Value` carries strings and numbers in its own fields, so there is no boxing and no decoding. With the built-in handlers this is usually the difference between a handful of allocations and zero or one. **3. Guard the arguments you would rather not build.** Go evaluates every argument before the call runs, so a Debug line whose level is off in production still executes whatever you passed it. Wrap those in `if logger.Enabled(ctx, slog.LevelDebug)`. On a line that is genuinely enabled this buys nothing; on a disabled one in a 40k/s loop it removes the whole argument. **4. Take the payload off the line.** This is usually the largest single item and the easiest to miss, because it costs bytes rather than allocations. Attaching the record's raw `[]byte` payload means the handler renders every byte of it into every line — and the built-in JSON handler, having no typed path for a `[]byte`, marshals it through `encoding/json`, which renders it as a base64 string. A 4 KB payload turns a 200-byte line into something twenty times larger, per record, at 40k records a second. Log an identifier and `len(payload)` instead; the payload is already somewhere you can go and fetch it. ## Do not forget the handler If the call site is already clean and the allocations persist, the handler is the suspect. A handler that builds a map per record, reaches for `fmt.Sprintf`, or allocates a fresh output buffer for each line will dominate anything the call site does. The built-in handlers reuse a buffer from a `sync.Pool` between records and hold a single lock only around the write; that is the bar to compare against. Benchmark the same record through `slog.NewJSONHandler` and through the handler you actually deploy, and if the gap is large the fix is in the handler, not in your call sites. ## What to leave alone Resist rewriting every log call in the service. The mechanical cost only matters where the call is hot; on a start-up line or an error path the variadic form is clearer and the difference is unmeasurable. And keep the changes behaviour-preserving: `With` plus `LogAttrs` emits exactly the same fields, so it is a safe change to make under load. Dropping the payload attribute is the one change that alters the line, and it is worth agreeing with whoever queries those logs before you make it. ## The order matters The sequence above is deliberately cheapest-first in engineering effort and largest-first in effect: measure, bind the constants, retype the variables, guard the expensive, shrink the payload, then question the handler. Stop as soon as the benchmark says you are done — the last two steps cost real time and are wasted if the first two already took the line from six allocations to one.