ProcessPool vs ThreadPool: GIL CPU Lab with Real Numbers

Intro — what this post promises

“Just add more threads” is the wrong answer for pure-Python CPU work. The GIL makes that a trap. “Always use processes” is also wrong when the work is waiting, not computing.

This is a hands-on lab with measured numbers:

1. ThreadPoolExecutor vs ProcessPoolExecutor vs serial on 16 identical tasks.
2. Three workloads: pure-Python math (holds the GIL), hashlib.sha256 (releases the GIL in C), and time.sleep (I/O-wait).
3. Worker sweeps at 1 / 2 / 4 / 8 on an 8-core box.
4. When threads help, when they hurt, and when process spawn cost shows up.

Related links:

• Go GC + swap on a tiny VPS
• JVM heap vs RSS vs OOM on 512 MB
• Why your average latency graph is lying (p50 / p95 / p99)
• Pipe vs tmpfile IPC localhost lab

Lab honesty (30 Sep 2026 IST): Shared Linux lab box (8 cores, kernel 6.12). Python 3.13.5. concurrent.futures only. Local CPU + sleep — no sockets, no Docker, no GPU, no API keys. Affiliates: 0.

Verdict up front: pure-Python CPU — threads 0.82× at 4 workers (slower than serial); processes 2.41× / 3.48× . hashlib — threads 1.60× ; processes still 3.17×. Sleep I/O — threads 7.87× vs processes 6.30× .

What we compared

Pool API: ThreadPoolExecutor / ProcessPoolExecutor with max_workers ∈ . Metric: wall time p50 over 3 rounds for all 16 tasks.

Related links:

• concurrent.futures — Python docs

Lab topology

16 identical tasks · serial | ThreadPool | ProcessPool
Workers: 1 / 2 / 4 / 8 (8-core box)
Arms: pure-Python CPU · hashlib.sha256 · time.sleep(0.05)
Metric: wall seconds (p50 of 3 rounds)

Arm A — pure-Python CPU (GIL-bound)

Threads never beat serial here — more workers made it worse. Processes scaled roughly with cores until spawn/overhead flattened the curve.

Arm B — hashlib.sha256 (GIL released)

C extensions that release the GIL let threads help — but processes still won big, and thread w=8 regressed vs w=4 on this shared box (contention / scheduling noise).

Arm C — sleep I/O-wait

When tasks mostly wait, threads are enough — and slightly cheaper than forking eight workers for 50 ms sleeps.

Related links:

• Pipe vs tmpfile IPC localhost lab
• epoll vs select FD_SETSIZE lab

When threads still win the design

• I/O-bound / wait-bound work (network, disk, sleep, locks you release around).
• C extensions that release the GIL (hashlib, many crypto/compress codecs) — measure; do not assume.
• Shared in-memory state you do not want to pickle across processes.
• Tiny tasks where process spawn + IPC dwarfs the work (Arm C’s process tax).

Reach for processes when the hotspot is pure Python (or any code that holds the GIL for long stretches).

Pitfalls we hit (or avoided)

1. “Threads = parallelism” for pure Python — Arm A is the counterexample (0.82×).
2. Assuming hashlib needs processes — threads helped (1.6×); processes still better if CPU-bound hashing dominates.
3. More workers always better — thread hashlib w=8 regressing vs w=4.
4. Ignoring process start cost — Arm C: threads edged processes at 8 workers.
5. Calling this an asyncio result — this lab is thread/process pools, not the event loop.

Practical checklist

• Profile: is the hot path pure Python or C / I/O?
• Pure-Python CPU → ProcessPoolExecutor (or another process model); do not expect thread speedups.
• Wait-heavy work → threads (or asyncio) first; measure before paying process overhead.
• Report workload type + worker count + wall p50 with every speedup claim.
• Cap workers near core count for CPU arms; I/O arms may want more — still measure.

Verdict

On this 8-core box with 16 tasks: pure-Python CPU — threads lost (0.82× workers); processes 2.41× / 3.48× . hashlib — threads 1.60× , processes 3.17×. Sleep I/O — threads 7.87× edged processes 6.30× at 8 workers. Match the pool to the GIL story, not the folklore.

Evidence path on the lab box: lab-evidence/24-process-vs-thread-pool/results/. Affiliates: 0.