Two engineers blame different per-record costs for a slow two-million-row loop, so how do you establish which one dominates?

## Why this is measured rather than argued A loop over records pays several distinct overheads once per record: resolving at run time what the values are, wrapping each value as a language object, assembling a record that is not stored anywhere, and whatever accumulating the results costs. All four are real. Their *sizes* differ by an order of magnitude depending on how wide the table is, how many rows there are, and which ecosystem you are in - which is exactly how two competent engineers end up holding opposite opinions with genuine evidence for each. There is a method, and it takes about ten minutes. ## Step one: scale the input before profiling anything Run the same loop at three sizes - *n*, 2*n*, 4*n* - and read the shape rather than the numbers. - **Roughly linear** (double the input, double the time): every cost in play is a constant per record. Now it is worth asking which constant is largest. - **Roughly quadratic** (double the input, quadruple the time): something is redoing work already done, almost always an accumulation that rebuilds the whole result on each iteration. Stop here. That term's share grows with the input, so it will dominate at production size no matter how the constants rank, and it is usually a few lines to fix. This single measurement orders the entire list. A profiler run first will cheerfully attribute most of its samples to the per-record surface and tell you nothing about the fact that the curve is bending. ## Step two: ablate, one component at a time With a linear curve confirmed, take the same loop and remove one thing at a time, re-timing each variant: 1. **Iterate and do nothing.** Walk the per-record surface with an empty body. This prices the record assembly and the wrapping on their own. 2. **Work, but discard the result.** Do the arithmetic and throw the answer away instead of accumulating it. The gap against the full loop is the accumulation's share. 3. **Narrow the table.** Reduce it to the columns the body actually reads and repeat variant 1. The gap is the width-driven part of the assembly. 4. **Walk one column's values instead of records.** Nothing is assembled at all, so what is left is the per-value costs. | variant | what its time contains | |---|---| | the full loop | everything | | iterate, empty body | assembly plus wrapping | | work, discard the result | everything except the accumulation | | narrowed table, empty body | assembly of the used columns, plus wrapping | | walk one column | per-value costs only | Four timings, three subtractions, and the ranking is measured instead of recited. ## What the answer usually looks like, with its conditions attached - **When the curve is superlinear**, the accumulation outranks everything, and the other three are not worth discussing until it is gone. - **On a wide table**, the record assembly usually leads among the constants, because it gathers and wraps one value from every column whether the body reads it or not. - **On a narrow table**, the wrapping and the run-time type decision usually lead, because there is barely anything to assemble. - **Where the host language is compiled and stores values unwrapped**, the type decision and the wrapping shrink sharply, since the operation is resolved before the loop runs and no object is built per value. Assembly and accumulation then take over. A ranking learned in one ecosystem does not transfer to another, which is a second and independent reason to measure. ## Traps that make the measurement lie - **Measuring at a convenient size.** A thousand-row benchmark hides the only superlinear term and over-weights any fixed setup. Measure at a size you actually run at, and at two sizes at minimum. - **Measuring once.** The diagnostic value lives in the ratio between sizes; a single number cannot produce a ratio. - **Timing the first run.** Warm-up, lazily initialised machinery and page faults all land in the first pass. Discard it, or amortise across repeats. - **Ignoring peak memory.** An accumulation problem shows as a memory curve as well as a time curve, and sometimes the memory curve is the one that actually hurts. - **Changing two things between variants.** Each ablation must remove exactly one component, or the subtraction means nothing. ## What to do with the ranking once you have it If the plan is to rewrite the loop as one expression over whole columns, all four overheads go at once and the decomposition was a diagnosis rather than a work list. The ranking earns its keep in the other cases: when a partial fix is needed today, when only part of the body has a whole-column form, and when you have to explain to a colleague why the obvious-looking change they proposed will not move the number at all.