Was ist TypePHP? AOT-Compiler, Benchmarks und Wann einsetzen

Was ist TypePHP? AOT-Compiler, Benchmarks und Wann einsetzen
Blog 6 Min. Lesezeit

Was TypePHP ist: Swoole-AOT, vs OPcache/JIT, offizielle Benches, Installation, Kompatibilität und gemessene Cloud-VPS-Minima.

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 AOTOPcacheJIT (PHP 8+)Swoole / FrankenPHP
Compile-ZielNativer Maschinencode (über C++17)BytecodeMaschinencode (trace-basiert)Weiterhin Zend/Runtime; langlebiger Prozess
Warm-upKeines zur Laufzeit (bereits kompiliert)Pro ProzessJIT-Warm-upWorker-Boot + Connection-Reuse
Natives ExecutableJa (bin-Modus)NeinNeinNein (außer Sie wrappen selbst)
Typischer GewinnNumerische / typisierte Hot Paths, PackagingKein Reparse pro RequestManche CPU-SchleifenConcurrency, 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.php gesamt: 5.034 s (interpretiertes PHP) → 0.603 s (TypePHP AOT) — etwa ~8×
  • micro_bench.php gesamt: 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.

ModusFlagOutputBraucht main()Typische Nutzung
Binary-m bin (Standard)ExecutableJaCLI-Tools, Services, Standalone-Apps
Extension-m extPHP .so / .dllNeinKompilierte APIs in eine PHP-SAPI laden
Library-m libShared Library + StubsNeinWiederverwendung 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.exe beim hello.php-Compile-Versuch: 34.6 MB (Compile stoppte, weil MSVC cl fehlte — 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

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.

typephp aot swoole php opcache jit compiler

EuroVDC

Cloud-Server-Power erleben

KVM-Virtualisierung · Sofort skalierbar · 24/7 Support

Cloud-Server mieten

Fanden Sie diesen Inhalt hilfreich?

– Person fand es hilfreich

In sozialen Medien teilen

Was ist TypePHP? AOT-Compiler, Benchmarks und Wann einsetzen