str.translate vs replace: Scrub Lab

Intro — what this post promises

Scrubbing characters: is str.translate faster than a chained str.replace or re.sub? This lab times delete, map, and combined tables on mid-size strings on Linux localhost (numpy-free, stdlib only).

Related links:

• string concat vs join localhost lab
• bytes vs bytearray localhost lab
• setdefault vs defaultdict localhost lab
• zip vs index pairing localhost lab
• functools partial vs lambda localhost lab
• itertools chain vs flatten localhost lab
• statistics vs manual mean localhost lab
• perf_counter vs time localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Delete set ≈ punctuation + tab/newline; map = vowels + digits → markers. Affiliates: 0. Short strings can favor few replace calls; longer scrub favors translate.

Verdict up front (len=2 000 delete): translate ~317M ch/s vs replace-chain (~8.1×) vs re.sub (~8.9×). Combined delete+map: translate ~9.6× chained replace. Prefer str.maketrans + translate for multi-char scrub.

Arms

Lab topology

lengths: 200 / 2000 / 20000; many trials on short strings
ops = full-string transforms/s; also chars/s

Script: lab-evidence/73-str-translate-vs-replace/results/run_lab.py.

Lead table — delete (p50 chars/s)

translate÷replace delete  k: ~8.1×;  k: ~7.0×.

Map & combined (len=2 000)

Honesty: with only 20 map chars, chained replace can beat translate map on short inputs (len=200: translate÷replace map ~0.32×). At len=20 000 translate map wins (~1.56×). Many deletes flip the story hard toward translate.

Reading it

• Many deletions / one pass — translate with a delete set is the winner (~8× replace at 2 k).
• Few substitutions on tiny strings — a handful of replace calls can win; still prefer translate for maintainability as the set grows.
• re.sub for char classes — usually last for this job; keep regex for real patterns.
• Build maketrans once — amortize table construction outside the loop.

When a few replace calls are enough

If you only fold three characters, chained replace can beat a general translate map on short inputs — fewer passes than a wide punctuation scrub, and less table machinery. The crossover is about how many distinct edits you apply per string, not a blanket “replace is slow.” Once the delete/map set looks like “all punctuation” or “normalize a keyboard row,” switch to maketrans and stop growing the chain.

Pitfalls

1. Chaining 50× replace for punctuation — quadratic-ish passes over the string.
2. Rebuilding translate tables every call — hoist maketrans.
3. Using regex for single-char deletes — translate is purpose-built.
4. Assuming replace is always slower — measure when the replace count is tiny.

When to pick what

Reproduce

python3 lab-evidence/73-str-translate-vs-replace/results/run_lab.py

Evidence: /workspace/lab-evidence/73-str-translate-vs-replace/results/.

Closing

translate for scrub tables; replace for tiny fixed edits; regex last. On this box len=2 k delete translate beat replace-chain by ~8.1× and re.sub by ~8.9×; combined scrub stayed ~9.6× ahead of chained replace. Build one table when the character set is non-trivial.