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:

./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

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

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.