sync.Pool and Reuse

## What a slice actually is A Go slice value is three words: a **pointer** to a backing array, a **length**, and a **capacity**. `len(s)` is how many elements are visible and indexable; `cap(s)` is how many the backing array can hold counting from the slice's first element. Only the length is a statement about data you have; the capacity is reserved room you already own. ## The two forms of `make` `make` takes a length and an optional capacity: - `make([]byte, 4096)` — length 4096, capacity 4096. The slice already **contains** 4096 zero bytes. - `make([]byte, 0, 4096)` — length 0, capacity 4096. The array is allocated and empty; nothing is visible yet. - `make([]byte, 10, 4096)` — length 10, capacity 4096. Ten zero bytes visible, room for 4086 more appends. All three perform exactly one allocation. What differs is where `append` starts writing. ## Why the capacity argument removes allocations `append` writes into the spare capacity when there is room. When there is not, it allocates a **new, larger** backing array, copies the existing elements across, writes the new ones, and returns a slice header pointing at the new array — which is why you must always write `s = append(s, x)`. Building a 4 KB payload from `var buf []byte` therefore costs several allocate-and-copy rounds: each round allocates a bigger array, copies everything written so far, and abandons the old array as garbage the collector must later sweep. Starting from `make([]byte, 0, 4096)` costs exactly **one** allocation and **zero** copies, as long as the data fits. That is the whole win: fewer allocations, no repeated copying, and less garbage. ## The trap the length form sets The commonest bug in this area is reaching for `make([]byte, n)` and then appending: ``` buf := make([]byte, 4096) buf = append(buf, data...) // len is now 4096 + len(data) ``` `append` adds **after** the existing elements, and the existing elements are 4096 zero bytes. The symptom is a response or a file that starts with 4 KB of NUL bytes and is 4 KB longer than expected. Pick the form by how you will fill the slice: - filling by **index** (`buf[i] = x`, `copy(buf, src)`, `r.Read(buf)`) — use the **length** form. - filling by **append** — use **length 0 with a capacity**. ## Maps take a hint too `make(map[string]int, 1000)` sizes the map's initial table for roughly a thousand entries so the runtime does not grow and rehash repeatedly while you fill it. It is a hint, not a limit: the map still grows past it, `len(m)` is 0 right after the call, and there is no `cap` for maps. ## Where preallocation pays, and where it hurts It pays when you know the count in advance and the loop is hot: `out := make([]Row, 0, len(rows))` before appending one element per input row turns a handful of allocations into one, on every call. It does not pay, or actively hurts, when: - the slice is tiny — one small allocation is cheap and the code is clearer without the ceremony; - you cannot estimate the size, and a wild guess reserves memory you never use; - the reservation is far too large — the **whole** backing array stays alive as long as any slice of it is reachable, so a 1 MB array kept for a 200-byte result wastes 1 MB indefinitely; - the capacity comes from **untrusted input**. `make([]byte, 0, hdr.Length)` where `hdr.Length` is client-supplied is a memory-exhaustion lever: validate against a maximum first, or grow naturally and let `append` bound the damage. ## Reserving is not the same as reusing Preallocating removes the allocations *within* one construction. Keeping the same buffer alive and refilling it removes the allocation *between* uses — the same array serving iteration after iteration, or request after request. They compose: reserve a sensible capacity once, then reuse that buffer rather than making a new one each time. ## What an interviewer is listening for That you can name the three parts of a slice header; that you know `make([]byte, n)` and `make([]byte, 0, n)` differ in the *length*, not the amount of memory allocated; that you can say what `append` does when capacity runs out; and that you do not treat "always preallocate" as a rule — you can name a case where reserving costs more than it saves.