Why does hoisting `self.rows.append` into a local before a hot loop help, when hoisting `out.append` barely does?

## Every dot is a runtime operation A dotted name in Python source is not a compile-time address; it is work the interpreter performs each time control reaches it. In the row loop of a payroll CSV import, `self.rows.append(line)` is three lookups per iteration: read the local `self`, look `rows` up on it, then look `append` up on the result. CPython compiles the second and third of those dots into their own `LOAD_ATTR` instruction, and each one runs the full attribute protocol on every pass. ## What LOAD_ATTR has to do `LOAD_ATTR` executes what `object.__getattribute__` describes: walk `type(obj).__mro__` looking for the name; if the class attribute found there is a data descriptor (it defines `__set__` or `__delete__`) it wins immediately; otherwise the instance `__dict__` is consulted; otherwise the class attribute is used, and if it is a non-data descriptor its `__get__` runs. Plain functions are non-data descriptors, which is exactly where a bound method comes from. None of that is free, and none of it is memoised by the source text. ## What an indexed local read has to do Locals are not stored in a dictionary. The compiler assigns each local name a slot index, recorded in the code object's `co_varnames`, and the instruction carries that index as its argument, so reading one is an array index into the frame's local slots: no hashing, no MRO walk, no descriptor check. On 3.14 `dis.dis()` prints most of these reads as `LOAD_FAST_BORROW`, which is new in 3.14; on earlier releases the same reads print as `LOAD_FAST`. Bytecode is version-specific, so a disassembly you memorised from an older release will not match line for line. ## Reading it off the disassembly Disassemble the two spellings and compare loop bodies rather than whole functions. The inline version's body carries two `LOAD_ATTR`s per iteration. The hoisted version's body carries none: the whole chain runs once before the loop, and each iteration reads one local and calls it. The `FOR_ITER` jump distance shrinks correspondingly, which is a quick visual check that the body really did get shorter. This is the concrete evidence to point at in an interview, instead of asserting that "attribute access is slow". ## The half that candidates get wrong Fewer instructions is not automatically faster, and on 3.14 the classic advice is half dead. Since 3.11 CPython specializes hot instructions, so a `LOAD_ATTR` at a call site that keeps seeing the same type is quickened into a much cheaper cached form. The consequence, which is the part that matters here, is that a single hoisted dot no longer buys anything: rewriting `out.append(x)` as `push = out.append` then `push(x)` measures as a wash on 3.14, and can come out marginally slower. There is a second reason for that. The inline call form compiles to `LOAD_ATTR` with the low bit of its argument set, which `dis.dis()` annotates as `append + NULL|self`; that form pushes the callable and the instance separately and never materialises a bound method object at all. The hoisted local, by contrast, holds a real bound method built by the one plain `LOAD_ATTR` before the loop. Where the hoist still earns its keep is when it removes a *chain*. `self.rows.append` is two attribute lookups per iteration, and lifting both out of a loop over ten thousand payroll rows measured a single-digit-percent improvement on 3.14. The rule that survives is not "hoist lookups" but "count the attribute lookups the loop body performs, and delete the ones that cannot change". ## What the hoisted name actually holds `xs.append is xs.append` is `False`, because each access constructs a fresh bound method object; `xs.append == xs.append` is `True`, because bound methods compare by their `__func__` and `__self__`. Hoisting simply performs that construction once instead of never. Two consequences follow. The binding is a snapshot: if `self.rows` is later rebound to a different list, or the method is patched, the loop keeps using the object captured before it started. And the local holds a strong reference to the owning instance for as long as the frame lives, which matters when the loop is long and the object is large. ## The judgement to show Use `dis.dis()` to explain the difference and `timeit` to decide whether it is worth having. Apply it only inside a loop that profiling has already identified as hot, because in ordinary code it trades a clear expression for an opaque one and buys nothing measurable. And treat the technique as the small end of the scale: deleting attribute lookups from a loop body is worth single-digit percentages, whereas restructuring the work so the loop runs fewer times, or does not run in pure Python at all, is worth multiples.