# Paralel Çalışanlar

Greph, iş yükü ek yükü karşılayacak kadar büyük olduğunda metin ve AST taramalarını çalışan havuzuna dağıtır. Havuz `pcntl_fork()` üzerine kuruludur ve `ext-pcntl` kullanılamadığında (Windows, bazı PaaS ortamları, kısıtlı barındırma) işlem içi yürütmeye geri döner.

## Paralel taramaları etkinleştirme

CLI üzerinde `-j N` ayarını yapın veya ilgili seçenekler nesnesinde `jobs: N` ayarını kullanın:

```bash
./vendor/bin/greph -F -j 8 "function" src
./vendor/bin/greph -p '$obj->$method($$$ARGS)' -j 4 src
./vendor/bin/rg --threads 8 -F "function" src
./vendor/bin/sg run --threads 8 --pattern '$obj->$method($$$ARGS)' src
```

```php
use Greph\Greph;
use Greph\Text\TextSearchOptions;

Greph::searchText(
    'function',
    'src',
    new TextSearchOptions(fixedString: true, jobs: 8),
);
```

## Paralel çalıştırmanın devreye girdiği durumlar

Greph koşulsuz olarak paralelleştirme yapmaz. N süreç oluşturmak ve sonuçlarını kanallar üzerinden gidip gelerek aktarmak ek yük getirir; küçük dosya listelerinde bu yük, arama işleminin kendisinden daha fazla olur. Bunun yerine facade, iş sayısı, arama modu ve desen biçimine göre bir eşik hesaplar. Yalnızca eşik değerin üzerindeki dosya listeleri çalışan havuzuna dağıtılır.

Güncel sezgisel kurallar (`Greph\Greph::shouldUseTextWorkers` ve benzerlerinde):

- Tek işli çalıştırmalar (`-j 1`) her zaman işlem içinde yürütülür.
- Varsayılan metin taramalarında havuzun devreye girmesi için yaklaşık `jobs * 2_000` dosya gerekir.
- Sayım, eşleşme içeren dosyalar ve eşleşme içermeyen dosyalar modlarında dosya başına iş daha hafif olduğundan eşik yaklaşık `jobs * 750` düzeyine iner.
- Kısa, tanımlayıcı biçimindeki sabit dizge desenleri eşiği yaklaşık `jobs * 4_000` düzeyine çıkarır; çünkü değişmez dizge hızlı yolu zaten çok ucuzdur ve süreç oluşturma nadiren kazanç sağlar.
- AST araması ve AST yeniden yazma işlemleri `jobs * 750` eşiğini kullanır.

Bu sayılar vaat değil, sezgisel tahminlerdir. WordPress kıyaslama külliyatına göre ayarlanmışlardır ve yeniden gözden geçirilebilirler.

## Havuzun çalışma şekli

`Greph\Parallel\WorkSplitter` dosya listesini N parçaya dağıtır. `Greph\Parallel\WorkerPool` her parça için bir çalışan süreci oluşturur; her çalışan aynı closure'ı kendi diliminde çalıştırır ve `Greph\Parallel\ResultCollector` her çalışanın sonuçlarını ayrı bir Unix soket çifti üzerinden okunabilir hale getirir. Üst süreç her çalışanın bitmesini bekler, ardından birleşik sonuç kümesini birleştirip yeniden sıralar. Böylece işin nasıl bölündüğünden bağımsız olarak çıktı sıralaması kararlı kalır.

Metin modunda çalışan havuzu, serileştirilmiş yükü küçük tutmak için özel bir kablo üzeri kodlayıcı (`Greph\Text\TextResultCodec`) kullanır. AST modu, PHP öğesinin standart `serialize()` biçimini kullanır.

## pcntl kullanılamadığında

`pcntl_fork` çağrılamıyorsa (Windows, sıkılaştırılmış PHP yapıları), havuz her parçayı işlem içinde çalıştırmaya sorunsuz biçimde geri döner. Sonuç, `-j 1` ile aynıdır. Greph hata vermez; yalnızca tek iş parçacıklı çalışır.

Bunu çalışma zamanında `function_exists('pcntl_fork')` değerini denetleyerek tespit edebilirsiniz.

## Ayarlama önerileri

- `-j` değerini fiziksel çekirdek sayınızın yarısına ayarlayarak başlayın ve iyileşme görmeyene kadar artırın.
- Küçük depolardaki yalnızca sabit dizge aramalarında tek süreç genellikle her türlü paralel yapılandırmadan daha hızlıdır.
- Paralel AST aramasını veya yeniden yazmayı ölçen yayımlanmış bir kıyaslama yoktur. İş sayısına karar vermeden önce kendi ağacınızda ölçüm yapın.
- README içindeki “Tarama Modu: Paralel Metin” satırları (`1`, `2` ve `4` çalışanlı, WordPress külliyatında) havuzu ölçmez: kısa sabit `function` değerini ararlar. Bu değerin `jobs * 4_000` dosyalık eşiği külliyat boyutundan büyük olduğundan, her satır işlem içinde yürütülür ([#8](https://github.com/inline0/greph/issues/8)).

## Sınırlamalar

- Mevcut havuz iş çalma özelliğini desteklemez. Bir parça diğerlerinden çok daha ağırsa havuz en yavaş çalışanın bitmesini bekler.
- Çalışan sonuçları, tüm çalışanlar işini bitirene kadar arabelleğe alınır. Uzun süren bir taramanın çıktı akışı (`rg --json` olayları akış halinde sunma biçimi) paralel modda desteklenmez.
- Üst süreç, sonuçları birleştirdikten sonra yeniden sıralar; bu nedenle çalışan havuzu, tek süreçli taramaya kıyasla tepe bellek kullanımını azaltmaz.

Bu sınırlamalar Greph hedeflediği iş yükleri (etkileşimli kod arama, aracı döngüleri, anlık görüntüler üzerinde CI işleri) için kabul edilebilir. Gerçek külliyatlarda performans profili bunların darboğaz olduğunu gösterirse yeniden ele alınacaktır.