zip vs Index Pairing: Loop Lab

Intro — what this post promises

Pairing two sequences: is zip faster than for i in range(n): (a[i], b[i]), and what does strict=True cost? This lab times materialize (list(zip)) and consume loops on Linux localhost.

Related links:

• 01shoppercove.comitertools chain vs flatten localhost lab
• 02shoppercove.comfunctools partial vs lambda localhost lab
• 03shoppercove.comitertools vs python loops localhost lab
• 04shoppercove.comnlargest vs sorted slice localhost lab
• 05shoppercove.comarray vs list ints localhost lab
• 06shoppercove.comstatistics vs manual mean localhost lab
• 07shoppercove.combisect vs linear lookup localhost lab
• 08shoppercove.comperf_counter vs time localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. One op = one pair. Affiliates: 0. zip truncates to the shorter input; strict=True errors on length mismatch.

Verdict up front (N=100 000 consume): zip ~26.8M/s vs index ~23.8M (~1.13×); list(zip) ~1.15× index comprehension. strict=True ≈ plain zip on equal-length consume (~0.98×). Prefer zip for clarity; index when you already need i.

Arms

Lab topology

N in {1000, 10000, 100000, 1000000}
also unequal truncate + 3-way zip consume

Script: lab-evidence/71-zip-vs-index-pairing/results/run_lab.py.

Lead table — consume N=100 000 / 1 000 000 (p50)

Index alone beat enumerate(zip) by ~1.7× — do not pay enumerate if you only need the parallel elements.

Materialize list(...) N=100 000

At N=1M materialize, index comp edged zip (zip÷index ~0.79×) — allocation/GC noise shows up; consume path still favored zip.

Unequal lengths & 3-way

zip truncate ~1.20× index-min; 3-way zip ~1.12× index3.

Reading it

• zip is the default pairing API — readable and usually as fast or faster on consume.
• strict=True is nearly free on equal lengths here — use it to catch bugs.
• Need the index anyway — range/enumerate on one sequence; avoid enumerate(zip) unless you need both.
• Materialize only if you need a list of pairs — otherwise iterate zip directly.

Why index sometimes “wins” on huge list(zip)

Building millions of tuple objects dominates. Small timing flips between zip and index comps at N=1M are about allocator behavior, not a reason to rewrite clear zip loops. Optimize the consume shape you actually run in production.

strict=True as production default

Equal-length zip is the common case; the bug is silently dropping a tail when lengths drift after a refactor. On this box the consume overhead of strict=True was noise (~1.00×). Prefer zip(a, b, strict=True) in new code unless you intentionally want truncation — and if you do, comment why.

Pitfalls

1. Silent truncation with plain zip on unequal inputs — prefer strict=True.
2. enumerate(zip(a,b)) when i unused — extra work.
3. Building list(zip(...)) just to iterate once — waste.
4. Assuming index is always slower — microbenches vary; API clarity still favors zip.

When to pick what

Reproduce

python3 lab-evidence/71-zip-vs-index-pairing/results/run_lab.py

Evidence: /workspace/lab-evidence/71-zip-vs-index-pairing/results/.

Closing

zip for pairing; strict for safety; index when you need i. On this box N=100 k consume zip led index by ~1.13×, strict matched zip, and enumerate(zip) trailed bare index by ~1.7×. Write zip first; reach for indices when the algorithm needs them.