attrgetter vs getattr: Hot Loop Lab

Intro — what this post promises

In a hot loop, is operator.attrgetter worth it over getattr, or should you just write .score? This lab times extract-to-list and list.sort(key=...) on Linux localhost for dataclass rows (plain + slots=True).

Related links:

• 01shoppercove.comitemgetter vs lambda sort localhost lab
• 02shoppercove.comCounter vs dict tally localhost lab
• 03shoppercove.comdataclass vs slots vs dict localhost lab
• 04shoppercove.comfrozenset vs set membership localhost lab
• 05shoppercove.combytes vs bytearray localhost lab
• 06shoppercove.comenum vs constants localhost lab
• 07shoppercove.comitertools vs python loops localhost lab
• 08shoppercove.comperf_counter vs time localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. N=50,000. Distinct from the itemgetter lab: focus is getattr builtin vs attrgetter vs direct attribute. Affiliates: 0.

Verdict up front: direct .score ~83M/s extract; attrgetter ~47M; getattr ~41M (direct ~2.0× getattr; attrgetter ~1.14× getattr). Sort gaps shrink: attrgetter vs getattr-lambda ~1.12×.

Arms

Lab topology

N = 50000 Row / RowSlots dataclasses
extract + sort arms; p50 ops/s (elements)

Script: lab-evidence/65-attrgetter-vs-getattr/results/run_lab.py.

Lead table — extract (p50)

Lead table — sort (p50)

Reading it

• Direct attribute wins extract — LOAD_ATTR beats a function call (~1.78× attrgetter, ~2.0× getattr).
• attrgetter beats getattr when you need a callable (~1.14× extract; ~1.31× with a dynamic name built once).
• Sort compresses gaps — Timsort dominates; attrgetter still edges getattr-lambda (~1.12×).
• getattr is for dynamic / optional names — not a faster .attr.

Direct vs callable: when the API forces a function

List comprehensions and straight attribute loads do not need a callable. map, sorted/list.sort key=, and similar APIs do. That is attrgetter’s niche: a tiny C callable bound to one or more names, reusable without a Python lambda wrapper. getattr remains the right tool when the name is data (config key, optional field) — just do not pay for it on a static .score path. Slots rows in this lab were a bit faster on direct access (~90M/s) but the ranking vs getattr stayed the same.

Pitfalls

1. Using getattr for a fixed name in a hot loop — write .score or attrgetter.
2. Rebuilding attrgetter(name) every call — bind once (dynamic arm builds once per timed run).
3. Optimizing sort keys before N hurts — tens of ns inside a ms-scale sort.
4. Confusing with itemgetter — tuples/dicts vs objects (see related itemgetter lab).

When to pick what

Reproduce

python3 lab-evidence/65-attrgetter-vs-getattr/results/run_lab.py

Evidence: /workspace/lab-evidence/65-attrgetter-vs-getattr/results/.

Closing

Dots first; attrgetter for callables; getattr for dynamism. On this box direct extract ~2.0× getattr and ~1.78× attrgetter; sort attrgetter still ~1.12× a getattr lambda. Reach for getattr only when the attribute name is not known statically.