tracemalloc Snapshot Cost: Localhost Lab

Intro — what this post promises

Cost of tracemalloc: start/stop, take_snapshot, compare_to, and allocation slowdown while tracing. Measured on Linux localhost.

Related links:

• 01shoppercove.comdataclass asdict vs vars localhost lab
• 02shoppercove.comgc collect cost localhost lab
• 03shoppercove.comsqlite3 vs shelve localhost lab
• 04shoppercove.comxml etree vs json localhost lab
• 05shoppercove.comlogging formatter vs fstring localhost lab
• 06shoppercove.comfractions vs float localhost lab
• 07shoppercove.commath fsum vs sum localhost lab
• 08shoppercove.comcopy copy vs dict copy localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Complements gc.collect cost (lab 129) — tracing overhead, not cyclic reclaim.

Verdict up front (n=20000 bytearrays): alloc without tracemalloc ~18152296 objs/s; with tracing ~1111095 (~16.3× slower). Hot snapshot ~7.28 ms (~137 snapshots/s).

Arms

Seven rounds, p50.

Lab topology

n_allocs=20000 × bytearray(64) · 7 rounds · p50

Script: lab-evidence/131-tracemalloc-snapshot/results/run_lab.py.

Lead table

Peak sample while tracing: 3891664 bytes (one-shot arm); loop peak 2593136.

Slowdown is the headline

Tracing made the alloc loop about 16.3× slower on this box. Leave tracemalloc off in production request paths; enable for canaries, repro scripts, or timed windows.

get_traced_memory stayed cheap (~298632 calls/s for the 10k batch) — fine for an occasional gauge if tracing must stay on.

Reading it for SRE work

• Leak bisect → start → exercise → snapshot → compare_to (budget ~158.312 ms here).
• Continuous prod tracing → expect multi-× alloc tax; prefer sampling profilers / RSS.
• Pair with lab 129 when the question is GC cycles, not allocation attribution.
• Always stop() in finally so a forgotten trace does not linger.

Snapshot vs compare

Hot take_snapshot was ~7.28 ms; compare_to(..., "lineno") jumped to ~158.312 ms. Diffing is the expensive report step — do it offline or rarely.

One-shot profiling window

The combined start → alloc → snapshot → stop path took ~27.038 ms end-to-end for 20000 allocations. That is acceptable for a canary or a failing unit repro; it is not a per-request tax. Prefer wrapping suspect code in a context manager that guarantees tracemalloc.stop() even on exceptions so workers do not silently stay in traced mode after a debug deploy.

Pitfalls

• Leaving tracemalloc on in multi-worker prod.
• Comparing peaks across runs without clearing/filters.
• Treating snapshot time as “free” in a latency SLO.
• Confusing traced bytes with RSS (arenas, other heaps).

Reproduce

python3 lab-evidence/131-tracemalloc-snapshot/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. Default tracemalloc frames. Not fil / memray.

Keep a before/after RSS note alongside traced peaks — tracemalloc explains Python allocations, not every mmap or allocator arena, so on-call should not equate the two gauges.

Filter snapshot statistics to your package paths before paging a human — unfiltered lineno diffs are noisy on large apps.

Takeaway

Alloc under tracemalloc ran ~16.3× slower (~1111095 vs ~18152296 objs/s). Use snapshots for investigations; do not leave tracing enabled on hot paths.