When does replacing strings.Split with strings.SplitSeq actually reduce allocations?

## What the slice-returning forms actually allocate A Go string is an immutable pointer-and-length pair. Because the bytes cannot change, a substring can safely share them, and `strings.Split` exploits that: every element of its result points into the *original* string's bytes. No character data is copied. What it does allocate is the backing array of the `[]string` itself. `Split` counts the separators first and makes one slice of exactly the right size, so the cost is one heap allocation per call, sized `count+1` string headers (16 bytes each on a 64-bit platform). The slice is returned, so it escapes and cannot stay on the stack. That is the entire budget, and knowing it stops two mistakes. The first is imagining that splitting a large line copies the line — it does not. The second is imagining the saving is bigger than it is: switching to an iterator removes one allocation per call, not a proportional cost. ## The iterator forms ```go func SplitSeq(s, sep string) iter.Seq[string] func FieldsSeq(s string) iter.Seq[string] func Lines(s string) iter.Seq[string] ``` Each returns a function you consume with `range`, yielding one substring at a time: ```go for field := range strings.SplitSeq(line, ",") { handle(field) } ``` The yielded values are the same substrings `Split` would have produced, still views into the input. No `[]string` is built, so the loop makes no allocation at all — the iterator closure itself is typically stack-allocated when it does not escape the calling function, which it does not in the pattern above. `SplitAfterSeq`, `FieldsFuncSeq` and the whole set of `bytes` equivalents exist too, so a `[]byte` pipeline gets the same treatment without converting to `string`. A `break` out of the loop simply stops the iteration; the iterator holds no resources to release. ## When the swap is worth making Ask two questions. **Is the call on a hot path?** One allocation is a handful of nanoseconds plus the garbage it eventually creates. In a broker client parsing thousands of frames a second, with several header lines each, that is a measurable share of the allocation rate, and allocation rate is what drives GC frequency. In a startup path, it is invisible, and the change is churn. **Do you actually consume the fields one at a time?** The iterator gives you exactly that and nothing more. If the next line of code is `len(parts)`, `parts[1]`, a sort, or a second pass, you need the slice — collecting the iterator back into one yourself just moves the allocation and adds a line. In particular, validating "this line must have exactly two fields" is a length check, and that argues for `strings.Cut` or `strings.SplitN` instead of either. ## Measuring rather than asserting The honest answer in an interview is that you measured it. A benchmark of the parse function, run with `-benchmem`, prints `allocs/op` and `B/op`; the swap should move `allocs/op` down by exactly one per split call, and `ns/op` by however much your allocator and GC were charging for that. If `allocs/op` does not move, the allocation you were chasing was somewhere else — commonly a `string([]byte)` conversion at the boundary, or a `map[string]string` being built from the parsed fields, both of which dwarf the split. That is also the review answer. A pull request that swaps `Split` for `SplitSeq` across a package without a benchmark is a change of style, not of performance, and it makes the code harder to read wherever the fields were genuinely wanted as a collection. ## The retention trap, which applies to both forms Because every substring points into the original string's bytes, keeping one field alive keeps the *whole* input alive. Parsing a 64 KB frame and storing a 12-byte header value in a long-lived map retains all 64 KB. This is not a reason to avoid `Split` or `SplitSeq` — it is a reason to copy explicitly (`strings.Clone`) when a small extracted value outlives the buffer it came from. Iterators do not change this either way. With `[]byte` there is an additional edge: the sub-slices returned by `bytes.Split` and yielded by `bytes.SplitSeq` alias a *mutable* array, so writing through one is visible through the original and through any overlapping neighbour. That is a correctness concern, not a performance one, and it is why byte parsers usually treat the yielded slices as read-only. ## Summary The iterator forms save the result slice and nothing else. Reach for them where a split runs per item on a hot path and the fields are consumed in order; keep the slice-returning forms where you need a collection; and let a `-benchmem` benchmark, not taste, decide which of those a given call site is.