Why does a surface that hands back one whole record per iteration cost more than reading only the two fields you need?

## A record is not stored anywhere The picture most people carry is a table as a stack of rows, so handing one back looks like reading a line off a page. That is not how these objects are laid out. A table here is a set of columns side by side, each one **a packed typed buffer** - values of a single representation laid end to end and addressed only by position. The row at position 500 is not stored as a unit at all. It is the 500th entry of the first column, the 500th entry of the second, and so on, in as many separate places as there are columns. So **the per-record iteration surface** - the surface that hands records back one at a time so you can write an ordinary loop over them - cannot point at a record. It has to construct one, on every iteration, before your body can name a single field. ## What one iteration actually costs For a table of *k* columns, one iteration does roughly this: - read one value out of each of the *k* packed buffers; - produce a language object for each of them, because your body will hold them as ordinary values rather than as bytes (**a boxed value**: a full object with its own header and a pointer to it); - build a container holding all *k* of them and hand it over; - discard the whole thing when the iteration ends. The body then reads two fields out of that container. The other *k* minus 2 were gathered, wrapped and thrown away. This is the part candidates miss: **the per-iteration cost tracks the width of the table, not the number of fields the body asked for.** Going from forty columns to two removes roughly ninety-five per cent of the gathering and wrapping from every iteration, and it is normally the cheapest change on the table. Note what does *not* change per iteration: the number of rows. More rows means the same cost paid more times, which is a different thing from a more expensive iteration, and keeping the two apart is most of what makes this question answerable. ## The flattening trap There is a second cost that is easy to miss because it changes the values, not just the timing. Some per-record surfaces build a container that carries **one** representation for all fields. A record spanning a whole-number identifier, a fractional measurement and a flag cannot keep three representations inside such a container, so the fields are brought to a single common one on the way out. Two things follow: 1. There is conversion work per field per row, stacked on top of the gathering and the wrapping. 2. The value you read back may not be the value that was stored. A whole-number identifier can arrive as a fractional value and then print, compare or serialise differently three steps downstream - a defect that is invisible at the loop and visible much later. Other surfaces build a heterogeneous record instead, where each field keeps the representation of the column it came from. Those cost less and distort nothing. Both kinds exist across this family, and they frequently sit side by side on the same object, so the useful habit is to establish which one you are holding before reasoning about either its cost or its values. ## The variables, separated | what changes | effect on one iteration | |---|---| | more columns in the table | proportionally more values gathered and wrapped | | more fields read in the body | almost nothing; they were all gathered anyway | | a flattened per-record container | a conversion per field, and representations that may shift | | a heterogeneous per-record container | no conversion; each field keeps its own representation | | more rows | no change per iteration, simply more iterations | ## What to do instead - **Narrow first.** If you must loop, reduce the table to the columns the body actually reads. The gathering cost falls with the width immediately and the change is one line. - **Walk columns, not records.** If the body reads two fields, take those two columns and step through their values in parallel. Nothing needs to be assembled at all. - **Prefer not to loop.** Expressing the body once for the whole column - working column-wise - removes the assembly rather than shrinking it, because columns are already the form the data is in. The shape of answer an interviewer is listening for is short: a record is assembled rather than stored, the assembly reads every column, so the cost is set by how wide the table is - and the real fix is to stop asking for records.