How The Fastest PHP Framework Can Smash Its Own Limits

In the high-stakes world of PHP framework benchmarks, a new ceiling has been established. Recent independent PHP framework benchmark tests have revealed that Trongate v2 has not only outpaced mainstream competitors but has also surpassed Phalcon - the long-standing benchmark champion of the PHP world.

Recording an astonishing 13,965 requests per second, Trongate v2 delivers approximately 30 times the throughput of Laravel 12. More significantly, it achieves this while remaining a 100% native PHP framework, requiring no compiled extensions or special server-level installations. Having already outperformed the best-known PHP frameworks, we have now identified a method to make it even faster.

Fig. 1 - Performance context: Trongate v2 throughput compared to mainstream alternatives.

What Exactly Is Being Said Here?

Normally, when a PHP framework or a new version is released, "Day One" is the fastest it will ever be. The reason? Feature creep - the gradual addition of new features, options, and abstractions over time, which collectively increase complexity and reduce performance.

This is something I observed with Trongate v1, and it left us with two choices:

1. Stop adding new features
2. Keep adding them - and accept slower performance

From the day Trongate v2 was launched, I assumed it was already at peak performance. However, thanks to an interesting discussion forum conversation, there is now genuine reason to believe that this rule can be broken. In short, we've found a way to make the framework even faster and significantly smaller.

What Are The Benefits?

Trongate v2 is already exceptionally fast and lightweight, so it's fair to ask why we'd push things further. Here's the honest answer.

Trongate already outperforms traditional PHP frameworks that rely on mechanisms such as PSR-4 autoloading, and by a wide margin. However, the real challenge begins when comparing Trongate to Phalcon, which is often cited as the fastest "PHP framework".

Fig. 2 - Same test conditions, Phalcon 5 included. PHP 8.5, debug off, live environment.

Phalcon's performance stems from its architecture as a Zend extension written in Zephir and C. Rather than existing as userland PHP code, it is compiled into a platform-specific binary module and loaded directly into the PHP process at startup. This allows it to bypass the overhead of tokenising and interpreting framework-level PHP during each request.

As a result, much of its execution occurs at the native machine-code level, outside the PHP virtual machine. This makes comparisons with pure PHP frameworks inherently uneven, since they operate under fundamentally different execution models. In that light, Trongate's ability to match or exceed Phalcon's throughput is particularly notable, given that it remains fully constrained by the PHP interpreter.

That said, in a recent conversation with Balázs Zatik, who conducted the benchmarks, he emphasised how close the contest between Phalcon and Trongate really was. Under different test conditions, Phalcon may even have come out ahead.

The idea of putting clear daylight between Trongate and Phalcon would settle, once and for all, the question of which PHP framework is the fastest. Call it ego, call it trivial, but we are here to win. If we can push Trongate further, we will.

Whilst additional speed might be dismissed as a vanity metric, the same cannot be said for reducing the size of the "engine" directory. In Trongate, the "engine" contains the framework's internal core. At the time of writing, it consists of roughly 2,000 lines of code, and there is an opportunity to reduce this even further.

A smaller core has practical benefits beyond performance. It improves AI-assisted development by reducing token usage and increasing the likelihood that tools can fully ingest and understand the framework. This leads to fewer hallucinations and more reliable assistance when building applications.

So, with the context established, let's explore how we can make Trongate even faster and smaller.

The War on "Dead Weight"

The primary bottleneck in modern PHP frameworks is not execution speed alone, but the cost incurred before application logic runs. On each request, PHP must load files, lex them into tokens, and parse them into executable opcodes.

Currently, Trongate's global helpers, covering forms, URLs, and strings, amount to roughly 80 KB of PHP source. In a traditional "fat helper" model, this code is included and parsed on every request, regardless of whether the functions are used. This creates unnecessary lexical and parsing overhead during the bootstrap phase.

The Service Routing Breakthrough

The proposed solution is a shift from "fat helpers" to a "Service Routing" architecture. In this model, helper functions become ultra-thin routing aliases, while the actual implementation logic is moved into dedicated service modules that are only invoked when needed.

Technically, this is achieved using PHP's __FUNCTION__ magic constant combined with variadic argument forwarding. A typical multi-line helper function can be reduced to a single-line dispatcher that passes execution to a central service layer.

The code snippet below offers a rough indication as to how this concept could work.

function do_the_work($caller, $val) {
    echo "Logic for {$caller} with value: {$val}\n";
    // Load a module and have the module do the work...
}

// Compact one-line definitions
function a($x) { do_the_work(__FUNCTION__, $x); }
function b($y) { do_the_work(__FUNCTION__, $y); }
function c($z) { do_the_work(__FUNCTION__, $z); }

This change has a direct impact on the PHP engine's workload. Instead of lexing and parsing large volumes of helper logic on every request, the engine processes only a minimal set of lightweight function definitions during bootstrap.

Why This Improves Benchmark Performance

Benchmark metrics such as requests per second and Time to First Byte are heavily influenced by bootstrap cost. Before your controller runs, PHP must process every included file. Reducing that workload produces measurable gains.

By eliminating roughly 60 to 70 KB of helper code from the mandatory execution path, we significantly reduce the amount of code that must be lexed and parsed on each request. In practical terms, this allows the engine to reach the controller faster.

Based on typical PHP runtime behaviour, this level of reduction is expected to yield a 2% to 5% improvement in request latency for simple endpoints such as the default homepage. While that may sound modest, in benchmark terms it is highly significant, especially at the level of performance Trongate is already operating at.

Crucially, this improvement is achieved without relying on caching layers such as OPcache warmup tricks or preloading strategies. It is a direct result of reducing the amount of PHP the engine must process on every request.

Compatibility and Design Integrity

This optimisation satisfies three critical constraints.

1. No breaking changes: Public function signatures remain identical, ensuring full backward compatibility.

2. No performance regressions: The reduction in bootstrap overhead results in faster, not slower, execution.

3. No additional complexity: This is an internal architectural change. Developers continue to use the framework exactly as before.

Why This Matters for Real-World Scalability

It is tempting to dismiss small percentage gains, but at scale they translate into substantial real-world benefits. Reduced bootstrap overhead means lower CPU usage, better concurrency, and improved response times under load.

More importantly, it increases headroom. With less framework overhead, more of the server's resources are available for application logic, database queries, and external integrations.

A New Standard for Native PHP

A framework achieving close to bare PHP throughput, while still providing routing, MVC structure, and security, demonstrates that overhead is largely a design decision.

The industry has long assumed that more features require more weight. Through Service Routing, we challenge that assumption. Trongate v2 is shaping up to be not just fast, but a demonstration of how efficient a PHP framework can be.

Everything is a module.

DC