Când alegi threading, multiprocessing sau asyncio?

Question

Accepted Answer

Python oferă trei modele de concurență, iar alegerea corectă depinde în principal de faptul că munca ta este **legată de I/O** sau **legată de CPU** — o decizie foarte influențată de GIL (care împiedică firele de execuție să ruleze cod Python în paralel).

## Cele trei modele

```text
threading        → multiple threads, ONE process. GIL-limited for CPU.
multiprocessing  → multiple PROCESSES, each its own interpreter/GIL → true parallelism.
asyncio          → single thread, cooperative coroutines yielding at await points.
```

## threading — pentru concurență legată de I/O

```python
from concurrent.futures import ThreadPoolExecutor

# ✅ good for I/O — the GIL is RELEASED during I/O waits, so waits overlap
with ThreadPoolExecutor(max_workers=10) as ex:
    results = list(ex.map(download_url, urls))   # many downloads concurrently
```

Firele de execuție funcționează bine pentru sarcini legate de I/O (rețea, fișiere, bază de date), deoarece GIL este eliberat în timp ce se așteaptă — multiple așteptări decurg simultan. Ele **nu** accelerează munca legată de CPU.

## multiprocessing — pentru paralelism legat de CPU

```python
from concurrent.futures import ProcessPoolExecutor

# ✅ good for CPU — separate processes each have their own GIL → use all cores
with ProcessPoolExecutor(max_workers=4) as ex:
    results = list(ex.map(heavy_computation, data))   # genuine parallelism
```

Pentru munca grea cu CPU (procesare de imagini, matematică, prelucrare de date), procesele separate ocolesc GIL-ul unic și rulează cu adevărat în paralel pe mai multe nuclee. Costul: overhead mai mare (inițializarea procesului) și datele trebuie **serializate** între procese (fără memorie partajată în mod implicit).

## asyncio — pentru I/O cu concurență ridicată

```python
import asyncio
# ✅ best for MANY concurrent I/O operations (thousands) — lightest weight
await asyncio.gather(*(fetch(url) for url in urls))
```

asyncio gestionează un număr imens de operații I/O concurente pe un singur fir de execuție, mai eficient decât firele de execuție (fără overhead per-fir) — ideal pentru servere și cod de rețea cu concurență ridicată.

## Ghidul de decizie

```text
CPU-bound (computation)              → multiprocessing
I/O-bound, moderate concurrency      → threading (simple, works with sync libraries)
I/O-bound, HIGH concurrency          → asyncio (thousands of connections, but needs
                                       async-compatible libraries)
Mixed CPU + I/O                       → combine (e.g. asyncio + a process pool for CPU)
```

## De ce contează

Alegerea modelului de concurență corect este una dintre cele mai importante decizii de performanță în Python, iar a alege greșit (eroarea clasică: fire de execuție pentru munca legată de CPU, pe care GIL-ul o face inutilă) duce la cod care nu se scalează.

Logica ghidantă curge din GIL: **fire de execuție/asyncio pentru I/O-bound** (GIL eliberat în timp ce se așteaptă — concurența funcționează) și **multiprocessing pentru CPU-bound** (GIL-uri separate pentru paralelism real), cu asyncio preferat când concurența este foarte ridicată.

Înțelegerea punctelor forte ale fiecărui model, costuri (overhead de proces/serializare, cerințe de bibliotecă pentru asyncio) și decizia I/O-versus-CPU este esențială pentru scrierea codului concurent Python care oferă cu adevărat performanță.