Geçen hafta sunucudaki PHP’yi 8.1’den 8.5’e taşıdım ve bunu bir bakım işi olarak yazdım. Bu hafta radara giren araç, o sürümü bir ön koşul olarak istiyor. TypePHP, PHP kaynak kodunu C++’a, oradan da native makine koduna çeviren bir AOT (ahead-of-time) derleyici. Yani yazdığınız PHP’yi yorumlanacak bir betik olmaktan çıkarıp çalıştırılabilir bir ikili dosyaya dönüştürüyor.
Metafor hazır zaten: erimiş metal. PHP’nin bütün cazibesi akışkanlığında. TypePHP o akışkan şeyi bir kalıba döküp soğutuyor. Çıkan parça çok daha hızlı ve çok daha sağlam. Sadece artık istediğiniz şekli almıyor.
Peşinen söyleyeyim: bu tur depoyu klonlayıp kaynağı ve uyumsuzluk listesini okudum, derleyiciyi çalıştırıp kendi ölçümümü almadım. Aşağıdaki sayılar projenin kendi deposundan, tarih damgasıyla.
TypePHP tam olarak ne yapıyor?
TypePHP, PHP kaynak kodunu C++17’ye indirip native derleyiciyle makine koduna çeviren, açık kaynak bir AOT derleyicisidir. Üç çıktı üretebiliyor: çalıştırılabilir ikili dosya, PHP eklentisi (.so / .dll) ve paylaşımlı kütüphane.
İlginç tarafı şu: derleyicinin kendisi tamamen PHP ile yazılmış ve kendi kendini derliyor. tpc ikilisi, TypePHP’nin kendi PHP kaynağının TypePHP ile derlenmesiyle üretiliyor; bootstrap zincirinde C veya C++ yapıştırıcısı yok. Bu gösteriş değil, testtir: kendi derleyicisini derleyemeyen derleyici sizinkini de derleyemez.
Dinamik değerler, dahili fonksiyonlar ve reflection tarafı ise PHPX köprüsüyle Zend çalışma zamanına bağlı kalıyor. “PHP’yi tamamen terk ettik” iddiası yok: kullanıcı fonksiyonlarınız derlendikten sonra Zend opcode’u olarak çalışmıyor, gerisi yerinde duruyor.
Kurulum: üç komut, bir de derleyici zinciri
Composer tarafı gerçekten üç satır. Asıl iş, makinede bir C++ zincirinin ve PHP geliştirme başlıklarının bulunmasında.
# Ubuntu/Debian tarafındaki ön koşullar
sudo apt install build-essential cmake pkg-config libgmp-dev libmpfr-dev
# Projeye derleyiciyi ekle
composer require --dev swoole/typephp
# Derle
vendor/bin/tpc.php project.ymlResmi gereksinim listesi net: PHP 8.4–8.5 CLI, geliştirme başlıkları ve php-config; ikili dosya için eşleşen libphp.so; GCC 9+ veya Clang ile C++17; CMake 3.24+; Composer 2; GMP ve MPFR. Sunucunuzda hâlâ PHP 8.1 duruyorsa kapıdan içeri giremiyorsunuz.
İkili dosya modunda bir main() fonksiyonu zorunlu. En küçük örnek şöyle görünüyor:
<?php
function main(): void
{
echo "Hello World!\n";
var_dump(PHP_VERSION);
}Kalıbın şekli: neyi rehin veriyorsunuz?
Bir radar yazısında en çok okunması gereken bölüm burasıdır; depo sayfasındaki hız tablosu bunu anlatmaz. TypePHP, PHP’nin tamamını değil, tanımlı ve test edilebilir bir alt kümesini destekliyor. Uyumsuzluk listesinden öne çıkanlar:
- Global kapsamda çalıştırılabilir kod yok. Global seviyede yalnızca bildirim,
use,declareve sabit tanımı olabiliyor. Her satırın bir fonksiyonun içinde olması gerekiyor. main()imzası katı. Ya parametresiz ya da(int $argc, array $argv), ve dönüş tipivoid.- Değişken değişkenler yok.
$$vardesteklenmiyor. - Closure esnekliği kırpılmış.
Closure::bind(),bindTo()vecall()desteklenmiyor; closure ve ok fonksiyonları referans parametresi almıyor. - Referans oyunları bitiyor. Değişken sayıda referans parametresi (
&...$args) desteklenmiyor. - Generator yerine FiberGenerator. Bu da
instanceofkontrollerini ve reflection uyumunu bozuyor. - Tip çıkarımı geri alınamıyor. 0.8.0 ile birlikte çıkarılan
int,floatveboolyerel değişkenleri sabit native depolama kullanıyor.$i = 100yazdıysanız o değişken kalıcı olarak tamsayı; aynı değişkeniforeachanahtarı olarak yeniden kullanmanız reddediliyor.
Deponun kendi uyarısı da nazik değil: bir özelliğin README’de geçmemesi desteklendiği anlamına gelmiyor, uyumsuzluk listesine bakmanız isteniyor. Dürüst bir tavır. Ama pratikte şu demek: mevcut bir PHP projesini alıp derlemeye çalışmak bir “deneme” değil, yeniden yazma projesi.
Hız rakamları kimin ölçümü?
Depodaki tabloda php-src ile gelen resmi dil benchmark’ları var: bench.php için 5,034 saniyeden 0,603 saniyeye (yaklaşık 8 kat), micro_bench.php için 13,045 saniyeden 2,021 saniyeye (yaklaşık 6,5 kat), -O3 ile derlenmiş hâlde. Konteyner tarafında ise 10000×100000 elemanlık bir güncelleme döngüsünde PHP dizisi 67,6 saniye, TypePHP’nin std::array‘i 6,4 saniye, elle yazılmış C++ std::vector 6,2 saniye.
Rakamlar etkileyici. Ama ölçen, projenin kendisi. README’de de şu not duruyor: bu sayılar bir ölçüm anlık görüntüsüdür, performans garantisi değildir; PHP sürümü, derleyici, CPU ve bayraklar sonucu değiştirir, karar vermeden önce aynı makinede karşılaştırın. Bir projenin bunu kendi vitrinine yazması sık görülen bir şey değil, hakkını verelim.
Lisans, sürüm ve bakım durumu
29 Eylül 2026 itibarıyla depo 1.417 yıldız, 79 çatal ve 0 açık konu gösteriyor. Depo 11 Mayıs 2026’da açılmış, son commit aynı gün, yani 29 Eylül 2026. Packagist’teki son sürüm v0.9.3 ve yayın tarihi 24 Eylül 2026; kaynaktaki sürüm sabiti de 0.9.3 diyor. Kurulum sayısı 19.091. Kısacası proje dört buçuk aylık ve hâlâ 0.x’te.
Lisans GPL-3.0-only. Bu, radar yazılarında genelde tek satırla geçilen ama burada geçilmemesi gereken bir ayrıntı: karşılaştırdığımız alternatiflerin hepsi MIT veya Apache-2.0. Projenin kendi tanıtım sayfası ücretsiz, açık kaynak (GPL) ve serbestçe ticari kullanılabilir diyor. Kapalı kaynak bir ürün dağıtacaksanız bu cümleyle yetinmeyin, lisans metnini okuyun.
Emeğin sahibi: proje Swoole ekibinden geliyor. composer.json‘daki telif sahibi 上海识沃网络科技有限公司 (Swoole), Packagist’teki paket bakımcısı ise Tianfeng Han (matyhtf). Aynı ekibin swoole-src deposu 18.923 yıldızla ve Apache-2.0 lisansıyla ayrıca duruyor; yani bu, dün kurulmuş bir ekibin ilk denemesi değil.
Alternatiflerle nerede ayrışıyor?
“PHP’yi binary yapmak” cümlesi piyasada en az dört farklı şeyi anlatıyor ve karıştırıldığı için yanlış araç seçiliyor. Yıldız sayıları 29 Eylül 2026 itibarıyla.
| Araç | Gerçekte ne yapıyor | Lisans | Yıldız | Şu iş için |
|---|---|---|---|---|
| TypePHP | PHP’yi C++ üzerinden makine koduna derler | GPL-3.0-only | 1.417 | CPU’ya yüklenen hesap döngüleri |
| FrankenPHP | Yorumlayıcıyı ve uygulamayı tek binary’ye gömer, derlemez | MIT | 11.371 | Dağıtımı tek dosyaya indirmek |
| static-php-cli | Taşınabilir statik PHP ikilisi üretir; kodunuz yine yorumlanır | MIT | 1.947 | Bağımlılıksız CLI aracı dağıtmak |
| Zephir | PHP benzeri ayrı bir dilden C eklentisi üretir | MIT | 3.385 | Sıfırdan yazılacak eklenti |
| Swoole | Coroutine tabanlı eşzamanlılık kütüphanesi; derleme yok | Apache-2.0 | 18.923 | G/Ç ile boğulan servisler |
Ayrım şu: FrankenPHP ve static-php-cli dağıtımı kolaylaştırır, Swoole bekleme süresini kısaltır, TypePHP ise hesabı hızlandırır. Derdiniz “tek dosya olsun” ise TypePHP’ye ihtiyacınız yok; “bu döngü CPU’yu yiyor” ise diğerleri size bir şey vermez.
Benim tarafımda nereye oturur?
Gündelik işimin ağırlığı çerçevesiz düz PHP, MariaDB, biraz Vue ve Linux tarafı. Bu yığında TypePHP’nin adresi belli: gecelik toplu işler. Katalog içe aktarımı, fiyat ve kâr marjı yeniden hesaplama, rapor üretimi gibi, tek bir CLI betiğinin milyonlarca satırın üstünden geçtiği yerler. Şekilleri zaten TypePHP’nin istediği kalıba yakın: her şey fonksiyonlarda, tipler belli, dinamik numara yok.
<?php
function kdvEkle(float $net, float $oran): float
{
return $net * (1.0 + $oran / 100.0);
}
function toplam(array $netler, float $oran): float
{
$sonuc = 0.0;
foreach ($netler as $net) {
$sonuc += kdvEkle((float) $net, $oran);
}
return $sonuc;
}
function main(): void
{
$netler = [1299.0, 89.9, 4550.0];
printf("%.2f\n", toplam($netler, 20.0));
}Bu parça düz PHP olarak geçerli (php -l ile doğruladım) ve dokümandaki kurallara göre biçimlendirildi: global kapsamda tek satır çalıştırılabilir kod yok, tipler açık, giriş noktası main(). Derleyip ölçmediğim için “şu kadar hızlandı” demiyorum.
Bir de dürüst olalım: bu betiklerde darboğaz çoğu zaman PHP değil. N+1 sorgu problemi veya yanlış sıralanmış WHERE koşulları duruyorken derleyici almak, tıkalı lavaboya daha güçlü musluk takmaktır.
Son bir not, codebase’ini ajanlara teslim edenler için: bu uyumsuzluk listesi bir stil tercihi değil, derleyicinin sözleşmesi. Ajan gayet emin bir tonla $$field kullanan kod üretir, o kod PHP olarak çalışır ve tpc tarafından reddedilir. Kuralı proje kural dosyasına yazmadan başlamayın.
Ne zaman işe yarar, ne zaman yaramaz?
Yarar: hesap ağırlıklı toplu işler; yeni yazılacak bir CLI aracı; PHP’den çağrılacak sıcak bir yolu eklenti hâline getirmek; PHP 8.4/8.5 ve tam bir derleyici zincirinin bulunduğu kendi sunucunuz.
Yaramaz: mevcut bir WordPress, Laravel veya eski bir kurumsal uygulamayı olduğu gibi derlemek; paylaşımlı hostingte çalışan projeler; darboğazı veritabanı veya ağ olan işler; GPL’in sizi rahatsız ettiği kapalı kaynak ürünler; 0.x sürüm numarasını kabul edemeyeceğiniz kritik sistemler.
Bu haftaki seri bölümünde lokal modellerin faturayı kaldırmadığını, sadece kalemlerini değiştirdiğini yazmıştım. TypePHP de aynı ailedendir: kalıba döktüğünüz parça hızlanır, karşılığında PHP’yi PHP yapan esnekliği kalıbın içinde bırakırsınız. Kayıp değil, takas. Yeter ki neyi verdiğinizi bilerek verin.
Ölçmeden karar vermeyin, sürümü sabitleyin, lisansı okuyun. Teknolojiyle kalın.