subprocess.run vs Popen: Localhost Lab

Intro — what this post promises

Spawn a tiny process many times: subprocess.run vs Popen + communicate. This lab reports launches/s for /bin/true, captured echo, and a short seq stdout capture on Linux localhost.

Related links:

• 01shoppercove.comfutures as completed vs wait localhost lab
• 02shoppercove.comthreadpoolexecutor vs sequential localhost lab
• 03shoppercove.comasyncio gather vs taskgroup localhost lab
• 04shoppercove.comshelve vs pickle dict localhost lab
• 05shoppercove.comsecrets vs urandom localhost lab
• 06shoppercove.comscandir vs listdir localhost lab
• 07shoppercove.comtarfile vs zipfile localhost lab
• 08shoppercove.comtextwrap fill vs manual localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. No Docker. No shell=True.

Verdict up front: Popen+/bin/true ~1745.5 launches/s vs run ~1610.6. With pipes: Popen ~1499.8 vs run(capture_output=True) ~1309.5. Echo capture: run ~1136.3 ≈ Popen ~1177.9.

Arms

Lab topology

true: 200 launches × 5 rounds · p50
echo: 100 · seq 1..500: 50
metric: launches/s = n / p50_wall

Script: lab-evidence/95-subprocess-run-vs-popen/results/run_lab.py.

Lead table (p50 launches/s)

Reading it

• run ≈ Popen+communicate for these tiny commands — convenience tax is small (~1.08× at best for bare true).
• capture_output=True / PIPEs cost more than a no-pipe spawn (true: ~1610.6 → ~1309.5 launches/s).
• Prefer run for one-shot commands; use Popen when you need streaming, overlap, or custom pipe wiring.
• Spawning /bin/true 1000× is still an anti-pattern — batch work inside one process when you can.

Convenience vs control

subprocess.run is the recommended API for most cases. This lab’s numbers support that: you are not leaving meaningful launches/s on the table versus hand-rolled Popen for fire-and-wait. Reach for Popen when run cannot express the lifecycle.

Why seq flipped slightly

On seq 1 500, run edged Popen (~1065.0 vs ~998.8 launches/s). Noise and helper overhead dominate at this scale; treat them as tied. The durable lesson is pipe setup cost, not a permanent ranking.

Capture cost reminder

Opening pipes for a command that writes nothing (/bin/true) still pays pipe setup. Only request capture_output / PIPEs when you will read stdout/stderr. For status-only helpers, bare run/Popen.wait stays leaner (~1611 vs ~1309 launches/s on this box).

Overlap and streaming

run always waits for the child to exit before returning. If you must read partial stdout while the child still runs, or multiplex several children, Popen is the API. This microbench never overlaps children — it measures spawn+wait convenience — so treat streaming designs as a separate profile.

Security baseline

Pass argument lists, not interpolated shell strings. Both run and Popen are safe when shell=False (default) and argv is controlled. Throughput rankings do not change that rule.

Pitfalls

• shell=True with untrusted strings.
• Deadlocks if you use PIPEs without communicate / threads.
• Ignoring check=True / return codes.
• Measuring spawn microbenches and concluding “Python is slow” when the kernel exec dominates.

Reproduce

python3 lab-evidence/95-subprocess-run-vs-popen/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. /bin/true, /bin/echo, seq only. Not posix_spawn tuning, not shell pipelines.

Batch when possible

If a loop calls run hundreds of times for tiny helpers, consider one long-lived worker process or an in-process function instead — spawn overhead will dominate any run vs Popen delta.

Takeaway

Popen ~1745.5 /s vs run ~1610.6 /s for /bin/true; capture paths sit lower (~1309.5–1499.8). Default to subprocess.run; use Popen when you need lower-level control — not for a few percent on tiny spawns.