TypePHP е ahead-of-time (AOT) компилаторът на Swoole: пишете типизиран PHP, програмата се свежда до C++17 и се получава нативен бинарен файл, PHP разширение или споделена библиотека. Това не е „по-бърз OPcache“ и не е същият продукт като дългоживеещи Swoole worker-и или FrankenPHP. Това е стъпка на компилация, която разменя динамичната гъвкавост на PHP срещу нативен машинен код по горещия път.
Това ръководство обхваща какво е TypePHP, как се различава от OPcache и JIT, официалните езикови benchmark числа от README на проекта, практичен Linux инсталационен път, трите режима на компилация, за кого е подходящ (и за кого не), границите на съвместимост и измерени минимуми за Cloud VPS от нашите toolkit измервания. Официалните документи са на swoole.com/aot; източникът за компилатора е github.com/swoole/typephp. Не бъркайте с други „TypePHP“ страници, които обсъждат само runtime типизация.
Какво е TypePHP
Класическият PHP минава през Zend: parse → opcodes → (по избор OPcache) → (по избор JIT) → изпълнение. TypePHP променя модела на доставка. Съвместим типизиран PHP се превежда веднъж в оптимизиран C++17 и се свързва с PHPX и (според режима) libphp / Embed SAPI. Резултатът може да е самостоятелен изпълним файл без отделен php интерпретатор процес, зареждаемо разширение или библиотека за други проекти.
Проектът цели PHP 8.4–8.5, изисква C++17 toolchain (GCC 9+ / Clang или MSVC на Windows), CMake 3.24+, Composer 2 и библиотеки за висока точност (GMP, MPFR). Binary режимът на Unix очаква съответна Embed библиотека (libphp.so / libphp.dylib); ако липсва, build-ът може да предложи php-builder от php-src. Този auto-build е тежкият път за RAM и диск.
TypePHP е все още млад спрямо FPM WordPress хостинг. Третирайте го като компилатор за CPU-bound CLI инструменти, типизирани горещи пътища, нативно пакетиране и защита на кода — не като ключ „направи CMS-а ми 8× по-бърз“.
TypePHP срещу OPcache срещу JIT срещу Swoole / FrankenPHP
Тези инструменти решават различни проблеми. Смесването на маркетингови лозунги губи спринтове.
| TypePHP AOT | OPcache | JIT (PHP 8+) | Swoole / FrankenPHP | |
|---|---|---|---|---|
| Цел на компилацията | Нативен машинен код (през C++17) | Bytecode | Машинен код (trace) | Все още Zend/runtime; дългоживеещ процес |
| Загряване | Няма при runtime (вече компилирано) | На процес | JIT загряване | Старт на worker + reuse на връзки |
| Нативен изпълним файл | Да (bin) | Не | Не | Не (освен ако го обвиете сами) |
| Типична полза | Числови / типизирани hot paths, пакетиране | Без повторно парсване на заявка | Някои CPU цикли | Concurrency, постоянни връзки |
OPcache държи opcodes в споделена памет. JIT може да генерира машинен код за горещи следи в същия Zend процес. Нито едното не доставя самостоятелен нативен продуктов бинарен файл. Swoole и FrankenPHP държат PHP резидентен и променят I/O и concurrency; те не AOT-компилират приложението към C++. Работата на TypePHP е AOT нативен изход.
Официални benchmark числа (и какво не доказват)
README на TypePHP публикува езикови бенчмаркове от php-src bench.php и micro_bench.php, компилирани с -O3:
bench.phpобщо: 5.034 s (интерпретиран PHP) → 0.603 s (TypePHP AOT) — около ~8×micro_bench.phpобщо: 13.045 s → 2.021 s — около ~6.5×
Тези натоварвания натоварват извиквания на функции, достъп до свойства на обекти, масиви/hash, низове и control flow. Не са WordPress page-generation benches, не са Laravel HTTP throughput и не обещават същия множител за вашия CMS след уикенд миграция. README етикетира таблицата като snapshot от измерване на проекта: версия на PHP, CPU, флагове и разширения местят резултата. Сравнявайте на същата машина преди да планирате капацитет.
Отделен std-container микробенч в същото README показва PHP масиви под JIT при 67.6 s срещу TypePHP std::array при 6.4 s (близо до ръчно написан C++ std::vector 6.2 s) за голям update цикъл. Интересно за числова/контейнерна работа — не е CMS TTFB твърдение. Твърдения като „>10× срещу ZendVM“ четете като близки до маркетинг; основните цитирани числа тук са таблицата от README.
Инсталация на Linux
Два практични пътя: Composer пакет или предварително сглобен tpc release от GitHub.
Системни пакети
sudo apt update
sudo apt install -y build-essential cmake pkg-config libgmp-dev libmpfr-dev
# PHP 8.4 или 8.5 CLI + development headers + 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
# или: vendor/bin/tpc.php hello.php
Release бинарен файл и PHPX / libphp
Linux release архивите носят компилатора (и README); production Composer зависимостите са вградени в tpc. Съпоставете PHP ZTS ABI на архива с host PHP. За binary/shared изходи PHP_HOME трябва да съдържа bin/php-config, headers и lib/libphp.so. Ако липсва Embed libphp, TypePHP може да предложи php-builder от php-src — планирайте RAM и диск (вижте оразмеряването по-долу).
Официални документи: Install, Composer, Compile, Execution.
Бележка за Windows
Windows x64 toolkit-ите включват съответните PHP/PHPX runtime-и. Все пак ви трябва поддържан C++ компилатор (MSVC). Задайте PHP_HOME, PHPX_HOME и PATH според WINDOWS-SETUP.txt. За повечето екипи Linux остава основният compile host.
Hello world и три режима на компилация
<?php
function main(): void
{
echo "Hello World!\n";
var_dump(PHP_VERSION);
}
bin/tpc.php hello.php
./hello
Binary режимът изисква глобална main() (без параметри или main(int $argc, array $argv), връща void). Няма изпълними top-level statements; работата е във функции или методи.
| Режим | Флаг | Изход | Трябва main() | Типична употреба |
|---|---|---|---|---|
| Binary | -m bin (по подразбиране) | Изпълним файл | Да | CLI инструменти, услуги, standalone приложения |
| Extension | -m ext | PHP .so / .dll | Не | Зареждане на компилирани API в PHP SAPI |
| Library | -m lib | Споделена библиотека + stubs | Не | Повторна употреба от друг проект |
Има и --nano за VM-free Nano build-и без libphp, които отхвърлят eval / динамични include. Започнете с нормален bin, освен ако съзнателно ви трябва Nano.
За кого — и кога да не мигрирате
Подходящо: CPU-bound CLI помощни програми, batch процесори, типизирани числови pipeline-и, инструменти като нативен бинарен файл, екипи с C++ toolchain и PHP 8.4+, експерименти с контролируем код.
Неподходящо: класически FPM WordPress или „утре цялото Laravel приложение“, shared hosting без root/toolchain, код с eval, тежка runtime генерация на класове или reflection трикове, които TypePHP съзнателно отхвърля. TypePHP не е магически ускорител пред непроменен CMS.
Решение в едно изречение: ако ползата зависи от типизирани hot paths и приемате AOT ограниченията, прототипирайте малък CLI бинарен файл; ако зависи от HTTP плъгини и динамични WordPress филтри, останете на OPcache/JIT (Swoole/FrankenPHP само за concurrency — не заместител на AOT).
Граници на съвместимост
TypePHP следва PHP синтаксиса там, където е съвместим с AOT, с умишлени ограничения. Глобалният scope е само декларации. Изводените int/float/bool по подразбиране ползват фиксирано нативно хранилище. Някои силно динамични reference, declaration, closure и reflection модели остават неподдържани. Проверете списъка с несъвместими функции и документацията за съвместимост, преди да обещаете rewrite. „Ще направим TypePHP на съществуващия CMS“ без одит оставя миграцията наполовина.
Опитайте на EuroVDC Cloud VPS (измерени минимуми)
Измерихме официалния Windows TypePHP v0.9.4 toolkit на build хост (Docker/WSL там липсваха; Linux auto-build на php-src не беше изпълнен там). Записани числа:
- Windows toolkit zip: 56.77 MB; разархивиран на диск: 171.24 MB
- Linux release tarball (ориентиран към компилатора): 12.53 MB
- Peak working set на
tpc.exeпри опит за компилация наhello.php: 34.6 MB (компилацията спря, защото липсваше MSVCcl— peak RSS все пак отразява старта на компилатора)
За реален Linux експеримент със системни пакети, предварително сглобен tpc и C++ toolchain планирайте поне:
- ≥ 4 GB RAM, 2+ vCPU, ≥ 20 GB свободно дисково пространство → EuroVDC Cloud VPS Medium (4 vCPU / 4 GB) като практичен под
- При
php-builder/ Embedlibphpauto-build с удобен-j: ≥ 8 GB RAM → Cloud VPS Medium Plus (4 vCPU / 8 GB) - Shared hosting: не е подходящ
Поръчайте възел в София на Cloud Server, инсталирайте пакетите по-горе и компилирайте hello бинарен файл, преди да се ангажирате с продуктов rewrite. Мека проверка на пътя от нашия datacenter в София: Looking Glass.
Източници
- swoole/typephp — README, изисквания, benchmark таблица
- TypePHP инсталация (swoole.com/aot)
- Composer интеграция
- Compile документация
- Performance документация
- Compatibility документация
- Execution документация
- ITNEXT — TypePHP wants to make PHP faster
- Codex — Getting to Know TypePHP
Готови за експеримент? Поръчайте Cloud VPS Medium или Medium Plus, инсталирайте toolchain-а, компилирайте hello.php и тогава решете дали горещият ви път принадлежи на AOT TypePHP или остава на OPcache/JIT.