functools.reduce vs for-loop: Localhost Lab

Intro — what this post promises

Aggregate sequences with functools.reduce vs a plain for loop, with sum / math.prod as reference arms. This lab reports element ops/s on Linux localhost.

Related links:

• selectors vs select localhost lab
• literal eval vs json localhost lab
• cmath vs math hypot localhost lab
• signal vs event wakeup localhost lab
• uuid4 vs uuid1 localhost lab
• platform vs uname localhost lab
• shlex vs split localhost lab
• memoryview vs bytes localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Data: ints 1..200, repeated 5000 times.

Verdict up front: builtin sum ~405562698 elem-ops/s; for-loop add ~65071639; reduce(operator.add) ~59179970; reduce(lambda) ~29566082. Product: math.prod ~29886074 vs reduce mul ~24946185.

Arms

Seven rounds, p50. Metric: (n_outer × n_elems) / p50_s.

Lab topology

n_outer=5000 · n_elems=200 · 7 rounds · p50

Script: lab-evidence/142-reduce-vs-loop/results/run_lab.py.

Lead table (p50 elem-ops/s)

Sums equal (True); prods equal (True).

Reading it for SRE work

• Plain sums → sum() (order-of-magnitude win here).
• Products → prefer math.prod over hand-rolled reduce.
• reduce(operator.*) ≈ a tight loop; reduce(lambda…) paid extra call overhead (~29566082).
• Keep reduce for non-associative folds / custom combiners — not for + on ints.

Lambda tax

reduce(lambda a, b: a + b, …) fell to ~29566082 elem-ops/s vs operator.add ~59179970. If you must fold, pass operator functions, not lambdas.

Why reduce still exists

Custom reducers (merge dicts, combine metrics structs) are clearer as reduce(combine, items, init) than a 15-line loop — just do not use it to reinvent sum. On this box the loop edged reduce for add (~65071639 vs ~59179970); builtin sum still dominated both.

Document “use sum/prod unless combiner is custom” in style guides so reviews stop bikeshedding reduce micro-optimizations.

Builtin gap

sum at ~405562698 elem-ops/s is not a fair peer to a Python-level fold — it is the reminder that CPython already optimized the common case. Reaching for reduce to “look functional” on integer sums costs readability and loses about an order of magnitude versus sum here. For products, math.prod ~29886074 still beat both reduce and the hand loop.

If a code search finds reduce(operator.add, nums, 0) in a hot metrics path, swap to sum(nums) and re-bench once — that single change usually ends the discussion.

Pitfalls

• Teaching reduce as “the fast way” to sum.
• Using lambda reducers in hot paths.
• Forgetting math.prod exists (3.8+).
• Comparing without fixing element counts.

Reproduce

python3 lab-evidence/142-reduce-vs-loop/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box, small int lists. Not numpy reductions, not parallel folds.

Prefer readable builtins first; reach for reduce only when the combiner is genuinely custom and tested.

Keep microbench scripts beside production PRs so claims stay reproducible on the same box class.

Takeaway

Use sum / math.prod for numeric aggregates (~405562698 / ~29886074 elem-ops/s). reduce(operator.add) ~59179970 tracks a for-loop; avoid lambda reduce in hot code.