Optimization Patterns

Measure, Then Change Complexity

The dominant win is almost always a better algorithm or data structure — in on a list is O(n) while dict/set lookup is O(1):

ids = {r.id for r in rows}                 # build once
selected = [r for r in rows if r.id in ids] # O(1) per probe

Benchmark the change honestly:

import timeit
timeit.timeit(lambda: lookup(values), number=100_000)

Before touching code, run cProfile and confirm the hotspot is where you think. Then classify the candidate: loop removal (algorithmic), caching repeated work (memoization), or micro-tweaks (local binding, comprehension) — only the first two usually move the needle, and all three must be re-measured afterward to prove the win survived.

Caching What Is Pure

from functools import lru_cache, cache, cached_property

@lru_cache(maxsize=256)          # bounded LRU eviction, 3.8+
def parse(expr: str) -> AST: ...

@cache                             # unbounded — 3.9+, use only for small domains
def fib(n: int) -> int: ...

class Config:
    @cached_property               # computed once per instance, stored in __dict__
    def parsed(self): return json.loads(self.raw)

Hazards to state before an interviewer nods:

• Arguments must be hashable (no list/dict parameters)
• typed=False (default) makes f(1) and f(1.0) collide because hash(1) == hash(1.0) — pass typed=True when that matters
• Mutable arguments invalidate the premise — the cache keys on the value at call time, not later mutation
• Unbounded cache on a wide input domain is a memory leak wearing a speedup costume

Structure-Level Micro-Optimizations

Once algorithms and caching are right, these measurements-backed tweaks help hot paths:

Guardrails: __slots__ forbids new attributes; premature local-binding hurts readability. Interview answer: state the profile evidence, the chosen lever, and the before/after number.