TypePHP ist Swooles Ahead-of-Time-(AOT)-Compiler: Sie schreiben typisiertes PHP, das Programm wird nach C++17 abgesenkt und als natives Binary, PHP-Extension oder Shared Library erzeugt. Das ist nicht „schnelleres OPcache“ und auch nicht dasselbe Produkt wie langlebige Swoole-Worker oder FrankenPHP. Es ist ein Compile-Schritt, der dynamische PHP-Flexibilität gegen nativen Maschinencode auf dem Hot Path eintauscht.
Dieser Leitfaden erklärt, was TypePHP ist, wie es sich von OPcache und JIT unterscheidet, die offiziellen Sprach-Benchmark-Zahlen aus dem Projekt-README, einen praktischen Linux-Installationsweg, die drei Compile-Modi, für wen es sich lohnt (und für wen nicht), Kompatibilitätsgrenzen sowie gemessene Cloud-VPS-Größen aus unseren Toolkit-Messungen. Offizielle Docs: swoole.com/aot; Quelle für den Compiler: github.com/swoole/typephp. Nicht verwechseln mit anderen „TypePHP“-Seiten, die nur Runtime-Typing-Notizen behandeln.
Was TypePHP ist
Klassisches PHP läuft über die Zend Engine: Parsen → Opcodes → (optional OPcache) → (optional JIT) → Ausführen. TypePHP ändert das Auslieferungsmodell. Kompatibles typisiertes PHP wird einmal in optimiertes C++17 übersetzt und gegen PHPX sowie (je nach Modus) libphp / Embed-SAPI gebunden. Das Ergebnis kann ein Standalone-Executable sein, das ohne separaten php-Interpreter-Prozess startet, eine ladbare Extension oder eine Library für andere Projekte.
Das Projekt zielt auf PHP 8.4–8.5, braucht eine C++17-Toolchain (GCC 9+ / Clang bzw. MSVC unter Windows), CMake 3.24+, Composer 2 und High-Precision-Math-Bibliotheken (GMP, MPFR). Binary-Mode unter Unix erwartet eine passende Embed-Library (libphp.so / libphp.dylib); fehlt sie, kann der Build php-builder anbieten, um eine private Runtime aus php-src zu bauen. Dieser Auto-Build ist der schwere Pfad für RAM und Disk.
TypePHP ist relativ zu FPM-WordPress-Hosting noch jung. Behandeln Sie es als Compiler für CPU-gebundene CLI-Tools, typisierte Hot Paths, natives Packaging und Quellschutz — nicht als Drop-in-Schalter „mein CMS wird 8× schneller“.
TypePHP vs OPcache vs JIT vs Swoole / FrankenPHP
Diese Werkzeuge lösen unterschiedliche Probleme. Marketing-Slogans zu vermischen kostet Sprints.
| TypePHP AOT | OPcache | JIT (PHP 8+) | Swoole / FrankenPHP | |
|---|---|---|---|---|
| Compile-Ziel | Nativer Maschinencode (über C++17) | Bytecode | Maschinencode (trace-basiert) | Weiterhin Zend/Runtime; langlebiger Prozess |
| Warm-up | Keines zur Laufzeit (bereits kompiliert) | Pro Prozess | JIT-Warm-up | Worker-Boot + Connection-Reuse |
| Natives Executable | Ja (bin-Modus) | Nein | Nein | Nein (außer Sie wrappen selbst) |
| Typischer Gewinn | Numerische / typisierte Hot Paths, Packaging | Kein Reparse pro Request | Manche CPU-Schleifen | Concurrency, persistente Verbindungen |
OPcache hält Opcodes im Shared Memory. JIT kann Hot Traces im selben Zend-Prozess in Maschinencode umsetzen. Beides liefert kein eigenständiges natives Produkt-Binary. Swoole und FrankenPHP halten PHP resident und ändern I/O sowie Concurrency; sie AOT-compilieren die App nicht nach C++. TypePHPs Aufgabe ist AOT-nativer Output.
Offizielle Benchmark-Zahlen (und was sie nicht beweisen)
Das TypePHP-README veröffentlicht Sprachbenchmarks aus php-srcs bench.php und micro_bench.php, kompiliert mit -O3:
bench.phpgesamt: 5.034 s (interpretiertes PHP) → 0.603 s (TypePHP AOT) — etwa ~8×micro_bench.phpgesamt: 13.045 s → 2.021 s — etwa ~6.5×
Diese Workloads belasten Funktionsaufrufe, ObjekProperty-Zugriff, Array/Hash-Zugriff, Strings und Control Flow. Es sind keine WordPress-Seitengenerierungs-Benches, kein Laravel-HTTP-Throughput und keine Garantie, dass Ihr CMS denselben Faktor nach einer Wochenend-Migration erreicht. Das README kennzeichnet die Tabelle als Projekt-Mess-Snapshot: PHP-Version, CPU, Flags und Extensions verschieben das Ergebnis. Vergleichen Sie auf derselben Maschine, bevor Sie Kapazität planen.
Ein separater Std-Container-Mikrobench im selben README zeigt PHP-Arrays unter JIT bei 67.6 s versus TypePHP std::array bei 6.4 s (nahe handgeschriebenem C++ std::vector 6.2 s) für eine große Update-Schleife. Interessant für numerische/Container-Arbeit — kein CMS-TTFB-Claim. Aussagen wie „>10× vs ZendVM“ als marketingnah lesen; primäre Zahlen hier bleiben die README-Tabelle.
Installation unter Linux
Zwei praktische Wege: Composer-Paket oder vorgebautes tpc-Release von GitHub.
Systempakete
sudo apt update
sudo apt install -y build-essential cmake pkg-config libgmp-dev libmpfr-dev
# PHP 8.4 oder 8.5 CLI + Dev-Header + php-config
# Composer 2
RHEL/Fedora: dnf install gcc gcc-c++ cmake pkgconf-pkg-config gmp-devel mpfr-devel. CMake ≥ 3.24.
Composer
composer require --dev swoole/typephp
vendor/bin/tpc.php project.yml
# oder: vendor/bin/tpc.php hello.php
Release-Binary und PHPX / libphp
Linux-Release-Archive liefern den Compiler (und READMEs); Produktions-Composer-Dependencies stecken in tpc. Passen Sie die PHP-ZTS-ABI des Archivs an die Host-PHP an. Für Binary/Shared-Outputs braucht PHP_HOME bin/php-config, Header und lib/libphp.so. Fehlt Embed-libphp, kann TypePHP php-builder aus php-src anbieten — RAM und Disk einplanen (siehe Sizing unten).
Offizielle Docs: Install, Composer, Compile, Execution.
Windows-Hinweis
Windows-x64-Toolkits bündeln passende PHP/PHPX-Runtimes. Sie brauchen trotzdem einen unterstützten C++-Compiler (MSVC). Setzen Sie PHP_HOME, PHPX_HOME und PATH laut WINDOWS-SETUP.txt. Für die meisten Teams bleibt Linux der primäre Compile-Host.
Hello World und drei Compile-Modi
<?php
function main(): void
{
echo "Hello World!\n";
var_dump(PHP_VERSION);
}
bin/tpc.php hello.php
./hello
Binary-Mode verlangt eine globale main() (ohne Parameter oder main(int $argc, array $argv), Rückgabe void). Keine ausführbaren Top-Level-Statements; Arbeit gehört in Funktionen oder Methoden.
| Modus | Flag | Output | Braucht main() | Typische Nutzung |
|---|---|---|---|---|
| Binary | -m bin (Standard) | Executable | Ja | CLI-Tools, Services, Standalone-Apps |
| Extension | -m ext | PHP .so / .dll | Nein | Kompilierte APIs in eine PHP-SAPI laden |
| Library | -m lib | Shared Library + Stubs | Nein | Wiederverwendung aus anderem Projekt |
Mit --nano gibt es VM-freie Nano-Builds ohne libphp, die eval / dynamische Includes ablehnen. Starten Sie mit normalem bin, sofern Sie Nano nicht bewusst brauchen.
Für wen — und wann nicht migrieren
Gut geeignet: CPU-gebundene CLI-Utilities, Batch-Prozessoren, typisierte numerische Pipelines, Tools als natives Binary, Teams mit C++-Toolchain und PHP 8.4+, Experimente mit kontrollierbarem Quellcode.
Schlecht geeignet: Klassisches FPM-WordPress oder „morgen die ganze Laravel-App“, Shared Hosting ohne Root/Toolchain, Code mit eval, schwerer Runtime-Klassengenerierung oder Reflection-Tricks, die TypePHP bewusst ablehnt. TypePHP ist kein Magie-Beschleuniger vor einem unveränderten CMS.
Migrationsentscheid in einem Satz: Hängt der Gewinn an typisierten Hot Paths und akzeptablen AOT-Grenzen, prototypen Sie ein kleines CLI-Binary; hängt er an HTTP-Plugins und dynamischen WordPress-Filtern, bleiben Sie bei OPcache/JIT (Swoole/FrankenPHP nur für Concurrency — kein AOT-Ersatz).
Kompatibilitätsgrenzen
TypePHP folgt PHP-Syntax, wo sie mit AOT kompatibel ist, mit bewussten Einschränkungen. Globaler Scope ist deklarationsonly. Inferierte int/float/bool nutzen standardmäßig festen nativen Speicher. Manche hochdynamischen Referenz-, Deklarations-, Closure- und Reflection-Muster bleiben unsupported. Prüfen Sie die Incompatible-Features-Liste und die Kompatibilitätsdocs, bevor Sie einen Rewrite versprechen. „Wir TypePHP-en Ihr bestehendes CMS“ ohne Audit endet mitten in der Migration.
Auf einem EuroVDC Cloud VPS ausprobieren (gemessene Minima)
Wir haben das offizielle Windows-TypePHP-v0.9.4-Toolkit auf einem Build-Host gemessen (Docker/WSL dort nicht verfügbar; Linux-Auto-Build von php-src wurde dort nicht ausgeführt). Erfasste Zahlen:
- Windows-Toolkit-Zip: 56.77 MB; extrahiert auf Disk: 171.24 MB
- Linux-Release-Tarball (compiler-orientiert): 12.53 MB
- Peak Working Set von
tpc.exebeimhello.php-Compile-Versuch: 34.6 MB (Compile stoppte, weil MSVCclfehlte — der RSS-Peak spiegelt trotzdem den Compiler-Start wider)
Für ein echtes Linux-Experiment mit Systempaketen, vorgebautem tpc und C++-Toolchain planen Sie mindestens:
- ≥ 4 GB RAM, 2+ vCPU, ≥ 20 GB freier Disk → EuroVDC Cloud VPS Medium (4 vCPU / 4 GB) als praktischer Boden
- Bei
php-builder/ Embed-libphp-Auto-Build mit komfortablem-j: ≥ 8 GB RAM → Cloud VPS Medium Plus (4 vCPU / 8 GB) - Shared Hosting: ungeeignet
Bestellen Sie einen europäischen Node unter Cloud Server, installieren Sie die Pakete und kompilieren Sie ein Hello-Binary, bevor Sie einen Produkt-Rewrite committen. Soft Path Check aus unserem Sofia-Rechenzentrum: Looking Glass.
Quellen
- swoole/typephp — README, Requirements, Benchmark-Tabelle
- TypePHP Installation (swoole.com/aot)
- Composer-Integration
- Compile-Dokumentation
- Performance-Dokumentation
- Kompatibilitätsdokumentation
- Execution-Dokumentation
- ITNEXT — TypePHP wants to make PHP faster
- Codex — Getting to Know TypePHP
Bereit zum Experiment? Provisionieren Sie Cloud VPS Medium oder Medium Plus, installieren Sie die Toolchain, kompilieren Sie hello.php — und entscheiden Sie dann, ob Ihr Hot Path zu AOT-TypePHP gehört oder bei OPcache/JIT bleibt.