Why is reading a local variable cheaper than reading a global in CPython?

The three name-loading instructions you meet first in a disassembly — `LOAD_FAST`, `LOAD_GLOBAL`, `LOAD_ATTR` — are not three flavours of the same operation. They are three genuinely different amounts of work, and the difference is decided before your program runs. ## Scope is a compile-time decision When CPython compiles a function it builds a symbol table for the body. Any name **assigned** anywhere in that body — by `=`, `for`, `with ... as`, `import`, `def`, an augmented assignment — is a local for the *entire* body, including lines above the assignment. Locals are numbered and their names stored in `co_varnames`; the frame created for each call carries a flat array of that many slots. Two consequences follow. First, `LOAD_FAST n` is a pointer offset into that array plus a reference-count bump: no hashing, no dictionary, no fallback. Second, if the compiler decided a name is local and the slot is still empty when you read it, you get `UnboundLocalError`, not `NameError` — the slot exists, it just holds nothing. Names from an enclosing function are a third case: they compile to `LOAD_DEREF`, which reads a cell object and then its contents, one indirection more than a local and still far cheaper than a global. ## What a global read actually costs A name the compiler cannot prove local becomes `LOAD_GLOBAL`, whose oparg indexes `co_names`. At run time the interpreter hashes the name string and probes the module's global dictionary; on a miss it probes the builtins dictionary. So every bare `len`, `range`, `print` or `int` in a loop body is a dictionary lookup that misses once and hits once. The lookup must happen every iteration because the semantics demand it: any thread, any imported module, any line of code could rebind the module global between iterations, so the interpreter is not allowed to cache the value naively. `LOAD_ATTR` is heavier again. Evaluating `obj.attr` invokes `type(obj).__getattribute__`, which searches the type's MRO for the name; if it finds a **data descriptor** (a `property`, for example) that wins outright, otherwise the instance `__dict__` is consulted, and only then the class attribute or non-data descriptor — with `__getattr__` as a last resort on failure. A method access also builds a bound-method object. In 3.12 `LOAD_METHOD` was merged into `LOAD_ATTR`, so a method call now shows up as a single `LOAD_ATTR` with a flag bit set, followed by `CALL`. ## Hoisting, and its honest value The classic idiom follows directly: ```python def import_rows(rows, out): append = out.append # one LOAD_ATTR, once for row in rows: append(row) # one local read per iteration ``` Disassemble both spellings and the loop body shrinks from `LOAD_FAST` + `LOAD_ATTR` + `CALL` to `LOAD_FAST` + `CALL`. On the per-row loop of a payroll CSV import running against a 92nd-percentile latency budget, that can be the few percent you need. But be honest about the size of it: since 3.11 the interpreter caches global lookups per instruction, so the global-versus-local gap narrowed considerably, and the remaining win is mostly in attribute chains inside genuinely hot loops. Hoisting costs readability every time — a reader must now track an alias — so it belongs behind a measurement, never in a style guide. The same mechanism explains a favourite interview nugget: identical code runs faster inside a function than at module level, because at module scope *every* name is a global and there are no fast local slots at all. Wrapping a script's body in `def main():` is sometimes a free speedup. Writes mirror reads. Binding a local is `STORE_FAST`, a store into the same slot array, while binding a module global is `STORE_NAME` or `STORE_GLOBAL` into a dictionary. This is also why mutating `globals()` from inside a function cannot create a local: the compiler already decided which names are slots, and nothing done to a dictionary at run time can add one. It is the same fact seen from the other side — the shape of the frame is fixed when the function is compiled, not when it is called. ## Verifying rather than believing All of this is checkable in one line: disassemble the two versions and read the loop body. On 3.14 you will mostly see `LOAD_FAST_BORROW` rather than `LOAD_FAST` — a 3.14 addition that pushes a *borrowed* reference and skips the reference-count bump where the compiler can prove the value stays alive — and `LOAD_FAST_CHECK` where a local might legitimately be unbound. They are all the same family: an index into the frame's slots, and the cheapest name read Python has.