What TypePHP Means for the Future of PHP Performance

Direct answer: TypePHP is Swoole's open-source ahead-of-time (AOT) compiler that aims to turn typed PHP into C++ and then native code — a promising path for PHP performance, still early, and not a reason to delay shipping products on proven stacks like Laravel + Octane.

We watch this space closely at MarginTop Solutions because we run serious PHP workloads. Curiosity is free; holding your product roadmap hostage to an experimental compiler is not.

PHP performance: a brief, honest history

To understand what TypePHP is attempting, it helps to know where PHP has been. PHP's performance story over the last decade is actually one of the better ones in interpreted language ecosystems:

The JIT in PHP 8 disappointed some expectations because PHP web apps are largely I/O-bound, not CPU-bound. The JIT helps if you're doing heavy computation (image manipulation, ML inference in PHP, number-crunching). For a typical Laravel app spending 80% of its time waiting on database queries, the JIT delivers marginal gains. AOT compilation is trying to address a different layer.

What TypePHP is actually doing

TypePHP is Swoole's project to compile constrained, fully-typed PHP to C++ and then to native machine code via an AOT pipeline. Track it at github.com/swoole/typephp and swoole.com/aot.

The key constraints:

• It requires fully typed PHP — no dynamic types, no mixed ambiguity. This is the "constrained surface" that makes AOT compilation tractable.
• It targets hot paths — not your entire codebase, but the performance-critical sections that justify the compilation overhead.
• It sits at the intersection of Swoole's long-running worker model and native execution — conceptually similar to what HHVM attempted, but with different architecture choices.

The HHVM precedent: optimism with scars

PHP has seen this movie before. Meta built HHVM (Hip Hop Virtual Machine), which compiled PHP to C++ to native code, and in 2013 it was producing genuinely impressive performance numbers — some benchmarks showed 5–9× speedup over PHP 5.4 on their workloads. This was real. PHP.net was still on 5.x. The speed gap was enormous.

Then PHP 7 shipped in 2015 with the PHPNG engine and closed most of the gap. HHVM kept evolving; Meta pivoted it toward Hack (their typed superset). Today HHVM runs Hack, not PHP. The wider PHP ecosystem never really followed.

The lesson isn't that performance moonshots fail — HHVM genuinely worked at Meta's scale and on their codebase. The lesson is that ecosystem gravity, tooling compatibility, and migration cost decide adoption more than benchmark results. Laravel runs on TypePHP today the way it ran on HHVM in 2014: experimentally, with caveats.

Realistic outlook for TypePHP

Our current read:

• Promising research direction. AOT compilation with a typed PHP subset is architecturally sound. The question is whether the constraint (fully typed code) is compatible with real-world Laravel application codebases, which mix typed and untyped code extensively.
• Long ecosystem adoption road. For TypePHP to matter to most Laravel shops, it would need support from the major packages (Eloquent, Livewire, Filament, etc.) — all of which contain substantial untyped PHP. That's a multi-year migration even if TypePHP reaches production stability tomorrow.
• Not a reason to delay shipping. If your product needs better performance today, the path is: profile first, fix queries and N+1s, then evaluate Laravel Octane + Swoole. TypePHP is not in that toolkit yet.

Related production path we use today: Laravel Octane + Swoole for concurrent load.

What to actually watch for

If you want to track whether TypePHP becomes production-relevant, these are the signals that matter:

1. Laravel or a major ecosystem package shipping TypePHP-compatible typed versions.
2. A production case study from a company with a comparable codebase (not a benchmark script) showing real-world gains.
3. The Swoole team defining a stable AOT compilation API that frameworks can target.

Until any of those happen, TypePHP is interesting research to follow — not an architecture decision to make.

Key takeaways

• PHP performance has improved dramatically: PHP 7 was ~2× faster than PHP 5; Octane + Swoole delivers 3–10× throughput gains on framework-heavy workloads. The runtime is not your bottleneck in most apps.
• TypePHP attempts AOT compilation via a C++ intermediate step, targeting fully-typed PHP hot paths. The approach is architecturally sound but early.
• HHVM showed that PHP performance moonshots work — at scale, with the right codebase — and that ecosystem adoption is the harder problem than the technical one.
• Don't hold product decisions waiting for TypePHP. Profile your actual app; fix queries and architecture first; reach for Octane when boot time is the measured bottleneck.

Running serious PHP workloads and thinking about performance? Get in touch — we've thought about this problem from multiple angles at MarginTop.