contextlib vs try/finally: Cleanup Lab

Intro — what this post promises

Is contextlib.closing / ExitStack “free” compared with a manual try / finally? This lab times file-like open → read → close patterns on Linux localhost: native with, closing(), @contextmanager, and ExitStack vs bare try/finally.

Related links:

• 01shoppercove.comThreadPoolExecutor vs sequential localhost lab
• 02shoppercove.comitemgetter vs lambda sort localhost lab
• 03shoppercove.comperf_counter vs time localhost lab
• 04shoppercove.comlogging vs print localhost lab
• 05shoppercove.comcopy vs deepcopy localhost lab
• 06shoppercove.comlru_cache hit vs miss localhost lab
• 07shoppercove.comitertools vs python loops localhost lab
• 08shoppercove.comarray vs list ints localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. N=50,000 open/close cycles per arm. FakeFile stands in for objects that expose close() but may lack __enter__ (the closing() use case). Affiliates: 0. Not a correctness substitute — context managers still win for nested cleanup and exceptions.

Verdict up front: bare try/finally ~8.3M/s; native with ~4.3M (~1.9× slower); closing() ~2.9M (~2.8×); ExitStack + one closing ~0.54M (~15×). Prefer clarity; pay ExitStack only when you need dynamic stacks.

Arms

Lab topology

N = 50000 cycles/arm; repeats=9; metric = p50 ops/s
FakeFile: __slots__, read(), close(); optional CM protocol

Script: lab-evidence/60-contextlib-vs-try-finally/results/run_lab.py.

Lead table — FakeFile (p50)

BytesIO check

Same shape: try/finally ~3.7× closing() on this path.

Reading it

• Protocol cost is real but small in absolute ns — ~120 ns try/finally vs ~341 ns closing() per cycle. You will not see this on a disk read that takes milliseconds.
• ExitStack is for dynamic / many resources — here one-slot ExitStack was ~15× slower than try/finally; three-resource still ~6.4×. Worth it when resource count is data-driven.
• Native with beats closing() (~1.46×) when the object already implements the CM protocol — prefer implementing __enter__/__exit__ over wrapping.
• @contextmanager sits between closing and ExitStack (~883 ns) — generator setup shows up in a tight loop.

Why this still prefers context managers in prod

The microbench ranks bare try/finally first because it does the least work. Production code usually values exception-safe nested cleanup, readable scopes, and libraries that only expose close(). Paying a few hundred nanoseconds per enter/exit is rational next to any real I/O. Strip wrappers only after a profiler names the CM path.

Pitfalls

1. Microbenching cleanup and skipping I/O — the close path is rarely your bottleneck.
2. Hand-rolling nested finally — easy to leak on partial failure; ExitStack exists for a reason.
3. closing() on an object that already supports with — double-wrap noise.
4. Assuming ExitStack is “heavy” in wall-clock APIs — microseconds vs network RTT.

When to pick what

Reproduce

python3 lab-evidence/60-contextlib-vs-try-finally/results/run_lab.py

Evidence: /workspace/lab-evidence/60-contextlib-vs-try-finally/results/.

Closing

Correctness first; nanoseconds second. On this box try/finally hit ~8.3M/s vs closing() ~2.9M (~2.8×) and ExitStack-one ~15× behind. Use contextlib for safety and nesting; only strip it after a profiler points at the enter/exit path.