The same numbers are held once with column names and row labels, once as a bare rectangle - what does the labelling cost?

## The charge is three things, not one 1. **Bytes** - what the labels themselves occupy. 2. **Work per step** - metadata that has to be carried through, decided, and in some designs reconciled, on every operation. 3. **A second coordinate system** - two ways to name a row, which the code and the reader must keep straight. Only the first is what people usually mean by overhead, and it is often the smallest of the three. ## The bytes: names are cheap, row labels depend Field names are one short string per field. A table with forty fields carries forty strings whether it has a thousand rows or a hundred million, so measuring them is a waste of an afternoon. Row labels are per row, and what they cost turns entirely on where they came from: - **The default consecutive-integer labelling is close to free in several designs**, which hold it as a description of a range - a start, a stop and a step - rather than as materialised values. Nothing is allocated per row. - **A labelling set from an existing field materialises a full-length array** of those values, plus whatever lookup structure the design builds beside it so that finding a row by its label beats scanning for it. - **A label made of several parts costs one array per part**, and multiplies the work of bringing two label sets together. - **In a design with no row-identity concept, this whole line of the ledger is zero**, because there is nothing to store. So "the row labels cost nothing, they are just the row numbers" is true of exactly one case - the default labelling - and misleading everywhere else. ## The work per step Every operation on a labelled holding does something with the metadata as well as with the values: - it carries the field names through, and decides what the result's names are; - where an operation combines two operands and **both carry an identity per row**, it reconciles the two label sets before computing anything; - where only one operand carries identity, or neither does, there is nothing to reconcile and **position is the only correspondence** - which is cheap, and silently wrong if an operand has been reordered. The property worth stating is what this charge scales with. It is proportional to how many row labels there are and how complicated each one is, not to the width of the values or the cost of the arithmetic. On a narrow table with an elaborate label it can dominate the step; on a wide numeric computation over a simple label it vanishes into the noise. ## The second coordinate system The third charge is not measured in bytes or seconds. A row in a labelled holding can be named two ways: by where it sits, and by what it is called. The two coincide only while the labelling is the default consecutive integers and nothing has reordered the rows - which is to say at the beginning and rarely afterwards. Everyone reading the code then has to know which of the two a given line means. That cost is paid by the team rather than by the machine, and it produces wrong answers rather than slow ones, which makes it the expensive one. ## Which charge applies where | charge | rectangle by position | table with no row identity | table carrying row identity | |---|---|---|---| | bytes for field names | none | negligible | negligible | | bytes for row labels | none | none | near zero for a default labelling; a full-length array per part for one set from a field | | metadata carried per step | none | field names only | names, plus label reconciliation when both operands carry identity | | second way to name a row | no | no | yes | ## When the charge is worth paying - When the result has to be interpretable by someone who did not write the step that produced it. - When two holdings have to be matched by identity rather than by order. - When fields of unlike kinds must live in one holding. - When a lookup by label is a real part of the work, so the array and the structure beside it are buying something back. And when it is not: a dense numeric computation over values that are all one kind, where every step runs over the whole holding and nothing is matched by identity, pays all three charges and collects on none of them. ## How to say it in an interview Separate the three charges, then attach the precondition to each. Naming the default-versus-set distinction on the bytes, and the both-operands condition on the reconciliation, is what distinguishes someone who has measured this from someone repeating that labels have overhead.