Before flattening a renderer's point buffer, how do you establish that wrapping each point is what costs the time?

## Why this leaf ends in a measurement Every part of the wrapping story is plausible — allocations, headers, a second memory touch, scattered targets — and plausibility is exactly what makes it dangerous. A buffer can carry all of that overhead and still not be where a frame's time goes. The question an interviewer is really asking is whether you will rewrite storage on the strength of a mechanism you can recite, or on the strength of a number. ## Build the other arm first There is no useful measurement of the wrapped buffer alone; it tells you only that some work takes some time. The comparison needs the layout you would move to: a **flat block of the same numbers**, filled with the same data, driven by the **same access pattern** the renderer actually uses. If the renderer scans tiles in order, scan in order. If it touches points at scattered indices, do that — the two layouts differ most under a sequential scan and least under random access, so the access pattern decides how much the result is worth. ## The three readings 1. **Heap bytes per element.** Take the buffer's retained footprint and divide by the element count. If the result sits near the payload size, the values were never wrapped on this path and the whole investigation is over. If it sits several times higher, each element is carrying a header, padding and an address slot. 2. **Allocation rate and reclamation work.** Fill the buffer and watch how many objects are created and how much tracing follows. This attributes cost specifically to the per-point objects rather than to the traversal. 3. **Time per traversal, at several buffer sizes.** Sweep the element count so the working set moves from comfortably cached to far larger than cache, and record the ratio between the two arms at each size. ## Reading the result | what you observe | what it implicates | |---|---| | the gap only opens above a certain buffer size | locality — the pointer chase, once targets stop being cached | | the gap is present at every size and tracks allocation | the per-point objects: allocation, headers, reclamation | | footprint per element is near the payload | nothing was wrapped here; look elsewhere for the cost | | no gap at any size, footprint high | the cost is real but small next to the rest of the frame | ## Traps that make the benchmark lie - **Everything fits in cache.** A small buffer hides the second memory touch completely, because the target is already there. This is the single most common reason a microbenchmark shows no difference and production disagrees. - **The wrappers never escaped.** In a loop that creates and discards values without storing them, an optimizer can prove the wrapper is unobservable and keep the value in registers, so the measurement contains no wrapping at all. Store into a buffer that outlives the loop, as the renderer does. - **Freshly allocated wrappers land adjacent.** A buffer filled in one burst can scan almost like a flat block. Measure after the buffer has been updated in place for a while, which is what an aged heap actually looks like. - **The loop was eliminated.** If nothing consumes the traversal's result, there may be no traversal. Accumulate something the measurement reads back. - **Values inside a wrapper cache.** Some runtimes serve pre-made wrappers for a narrow range of values; benchmark with the coordinate range the renderer really produces, not with small test values. ## What the number licenses A measured gap is what turns a layout rewrite from an opinion into a proposal, and it also bounds the proposal: if the flat arm is a few percent faster, the rewrite is not worth its maintenance, and if it is several times faster on the sizes the renderer really uses, the argument makes itself. Record the buffer size, the access pattern and the element count alongside the number, because all three are part of the claim — the same comparison at a different size can honestly produce the opposite verdict.