آپ threading، multiprocessing یا asyncio کب منتخب کرتے ہیں؟

Question

Accepted Answer

Python تین concurrency models پیش کرتا ہے، اور درست انتخاب بنیادی طور پر اس پر منحصر ہے کہ آپ کا کام **I/O-bound** ہے یا **CPU-bound** — ایک فیصلہ جس پر GIL کا گہرا اثر ہے (جو threads کو Python code متوازی طور پر چلانے سے روکتا ہے)۔

## تین models

```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 — I/O-bound concurrency کے لیے

```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
```

Threads I/O-bound کاموں (network، files، DB) کے لیے اچھے کام کرتے ہیں کیونکہ انتظار کے دوران GIL release ہو جاتا ہے — متعدد waits بیک وقت آگے بڑھتے ہیں۔ یہ CPU-bound کام کو تیز **نہیں** کرتے۔

## multiprocessing — CPU-bound parallelism کے لیے

```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
```

CPU-بھاری کام (image processing، math، data crunching) کے لیے، الگ processes واحد GIL کو bypass کرتے ہیں اور حقیقتاً متعدد cores پر متوازی چلتے ہیں۔ قیمت: زیادہ overhead (process startup) اور data کو processes کے درمیان **serialize** ہونا پڑتا ہے (بطورِ default کوئی shared memory نہیں)۔

## asyncio — high-concurrency I/O کے لیے

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

asyncio ایک ہی thread پر بہت بڑی تعداد میں concurrent I/O operations کو سنبھالتا ہے، threads کی نسبت زیادہ efficiently (کوئی per-thread overhead نہیں) — servers اور high-concurrency network code کے لیے مثالی۔

## فیصلہ کرنے کی گائیڈ

```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)
```

## یہ کیوں اہم ہے

صحیح concurrency model کا انتخاب Python کے سب سے زیادہ اثر انگیز performance فیصلوں میں سے ایک ہے، اور اسے غلط کرنا (کلاسیکی غلطی: CPU-bound کام کے لیے threads، جنہیں GIL بے کار کر دیتا ہے) ایسے code کا باعث بنتا ہے جو scale نہیں کرتا۔

رہنما منطق GIL سے بہتی ہے: **I/O-bound کے لیے threads/asyncio** (انتظار کے دوران GIL release — concurrency کام کرتی ہے) اور **CPU-bound کے لیے multiprocessing** (حقیقی parallelism کے لیے الگ GILs)، جہاں concurrency بہت زیادہ ہو وہاں asyncio کو ترجیح دی جاتی ہے۔

ہر model کی طاقت، قیمت (process overhead/serialization، asyncio کی library requirements)، اور I/O-بمقابلہ-CPU فیصلے کو سمجھنا ایسا concurrent Python لکھنے کے لیے ضروری ہے جو واقعی performance فراہم کرے۔