PHP 8.x Performance Benchmarks: JIT, OPcache, and Real-World Speed Gains Explained

March 16, 2026

PHP 8.x is the most performant major version in the language’s 30-year history. The PHP 8 series covering versions 8.0 (2020), 8.1 (2021), 8.2 (2022), and 8.3 (2023) delivers measurable throughput gains over PHP 7.4 through 3 core engine-level changes: the Just-In-Time (JIT) compiler, a restructured OPcache, and language-level optimizations that reduce opcode count per request.

Independent benchmarks from the Phoronix Test Suite record PHP 8.2 executing synthetic workloads 2.9× faster than PHP 7.4 and approximately 10–15% faster than PHP 8.0. Real-world Laravel and Symfony applications show 20–35% fewer milliseconds per request after migrating from PHP 7.4 to PHP 8.1+.

For development teams choosing a runtime or planning an upgrade path, the benchmark data establishes PHP 8.3 as the highest-performing stable release available as of 2024. This article presents version-by-version benchmark results, explains the mechanisms behind each gain, and maps the data to practical PHP development decisions.

PHP 8.x Version Timeline and Performance Milestones

The PHP 8 series introduced 4 stable releases between November 2020 and November 2023. Each release carried distinct performance-focused changes that compound across versions.

PHP 8.0 (Nov 2020): Introduced the JIT compiler, Union Types, Named Arguments, and Match Expressions. JIT operates in 2 modes — Tracing JIT and Function JIT. Benchmarks record a 3× synthetic speedup over PHP 7.4 for CPU-bound tasks under Tracing JIT.
PHP 8.1 (Nov 2021): Added Fibers (first-class coroutines for async execution), Enums, Readonly Properties, and Intersection Types. Symfony 6 benchmarks show PHP 8.1 processing 18% more requests per second than PHP 8.0 on identical hardware.
PHP 8.2 (Dec 2022): Introduced Readonly Classes, Disjunctive Normal Form (DNF) Types, and deprecated dynamic properties by default. OPcache improvements reduced memory overhead by an average of 8% across tested WordPress workloads.
PHP 8.3 (Nov 2023): Delivered typed class constants, a new json_validate() function, improvements to the Randomness extension, and refined readonly property handling. PHP 8.3 records the lowest average latency per Symfony request — 5.7ms vs. 7.2ms on PHP 7.4 in controlled Phoronix benchmarks.

How the JIT Compiler Drives PHP 8 Speed Gains

PHP historically executes code through a 2-step process: the Zend Engine compiles PHP source into opcodes, then the OPcache stores and replays those opcodes.

JIT adds a third step — it compiles hot opcodes directly into native machine code at runtime, eliminating the Zend Engine’s interpretation overhead on frequently-executed code paths.

How the JIT Compiler Drives PHP 8 Speed Gains

The JIT compiler operates in 4 configurable modes, controlled by the opcache.jit INI directive:

Disable (0): JIT is inactive.
Tracing (1254 — recommended): Profiles execution traces and compiles the hottest paths. Delivers the highest throughput for CPU-intensive workloads (e.g., image processing, data transformation, mathematical computation).
Function (1205): Compiles entire functions. More predictable but less aggressive than Tracing.
On (1235): A balanced auto-selection mode suitable for general-purpose web applications.

For I/O-bound web applications — which describes the majority of Laravel, Symfony, and WordPress deployments — JIT contributes a modest 5–10% latency reduction because the bottleneck is database queries and network I/O, not CPU cycles.

JIT’s maximum gains appear in pure computation: PHP 8.0 under Tracing JIT solves a Mandelbrot fractal 4.5× faster than PHP 7.4 without JIT, per the official PHP JIT RFC.

How Much Faster Is PHP 8 Than PHP 7.4 in Real Benchmarks?

PHP 8.1 is, on average, 23% faster than PHP 7.4 for real-world web framework workloads. The exact speedup depends on 3 variables: the application type, JIT configuration, and the ratio of CPU work to I/O operations.

The table below summarizes benchmark results from Phoronix Test Suite 10.8 running on an AMD EPYC 7302 server with 32 GB RAM, Ubuntu 22.04 LTS, and Nginx 1.22:

PHP Version	Symfony Requests/sec	WordPress Requests/sec	Mandelbrot (lower = faster, ms)	Relative to PHP 7.4
PHP 7.4	1,210	892	3,840 ms	Baseline
PHP 8.0 (JIT off)	1,318	961	3,610 ms	+8.9%
PHP 8.0 (JIT Tracing)	1,401	990	855 ms	+15.8%
PHP 8.1 (JIT Tracing)	1,652	1,078	810 ms	+36.5%
PHP 8.2 (JIT Tracing)	1,731	1,109	782 ms	+43.1%
PHP 8.3 (JIT Tracing)	1,798	1,147	764 ms	+48.6%

Source: Phoronix Test Suite benchmarks, AMD EPYC 7302, Ubuntu 22.04 LTS, Nginx 1.22. JIT buffer set to 128 MB for all JIT-enabled runs.

The data establishes 3 clear conclusions: (1) JIT alone contributes a 6.9% gain on top of PHP 8.0’s non-JIT improvements; (2) PHP 8.1’s Fibers and internal engine optimizations drive the largest single-version jump (+20.7% over 8.0 with JIT); (3) PHP 8.2 and 8.3 deliver incremental but compounding gains, collectively adding another 12.1% over 8.1.

OPcache Improvements Across PHP 8.x Versions

OPcache is PHP’s in-memory opcode cache. It eliminates repetitive source compilation by storing compiled opcodes in shared memory, making it the single highest-impact performance optimization for any PHP application.

PHP 8.x improves OPcache in 3 dimensions: preloading depth, inheritance cache, and memory efficiency.

OPcache Improvements Across PHP 8.x Versions

OPcache Preloading (PHP 8.0+)

PHP 8.0 stabilized the opcache.preload directive, allowing applications to precompile an entire codebase into shared memory at server startup. A preloaded Laravel 9 application resolves 40–60% of its autoloaded classes from shared memory on the first request, reducing cold-start latency from ~45ms to ~18ms on a standard VPS.

Inheritance Cache (PHP 8.1+)

PHP 8.1 introduced an Inheritance Cache that stores pre-resolved class hierarchies in OPcache. Before this, PHP re-resolved parent class methods and interface implementations on every request. The Inheritance Cache reduces class-loading time by up to 20% for frameworks with deep inheritance trees, such as Symfony’s DependencyInjection component.

Memory Savings in PHP 8.2

PHP 8.2 deprecated dynamic properties on non-stdClass objects. This change lets the engine pre-allocate fixed object memory layouts at compile time rather than dynamically at runtime, reducing peak OPcache memory consumption by 5–8% in applications that correctly declare all class properties.

PHP 8.1 Fibers and Asynchronous Execution Performance

PHP 8.1 introduced Fibers — a native implementation of stackful coroutines defined in RFC: Fibers. Fibers allow a single PHP process to suspend and resume execution at defined points, enabling cooperative multitasking without spawning OS threads.

In a traditional synchronous PHP request, an application blocks for the full duration of each database query or HTTP call. With Fibers and an event-loop library (such as ReactPHP or Revolt), 1 PHP-FPM worker handles multiple suspended I/O operations concurrently. Benchmarks on a 4-core server processing 500 concurrent HTTP client requests show:

Synchronous PHP 8.0: 42 requests/sec (worker pool saturated at 10 workers)
Fiber-based PHP 8.1 with ReactPHP: 310 requests/sec (same 10 workers, I/O overlapped)

Fibers do not reduce the CPU time of a single request. They increase overall system throughput by keeping workers productive during I/O wait periods. Teams building high-throughput backend APIs should evaluate Fiber-compatible event loops as part of their PHP 8.1+ migration.

PHP 8.x Language Features That Reduce Execution Overhead

Beyond JIT and OPcache, PHP 8.x introduces language constructs that the Zend Engine executes with fewer opcodes than their PHP 7.x equivalents. Each construct contributes a micro-optimization that aggregates into measurable throughput improvements at scale.

Match Expressions vs. Switch Statements

The match expression (PHP 8.0) compiles to a jump table in Zend opcodes, whereas switch compiles to a linear comparison chain. For a 10-branch conditional, match resolves in O(1) time; switch resolves in O(n) worst case. On a route dispatcher executing 100,000 lookups/sec, replacing switch with match reduces CPU time by 12–18%.

Named Arguments

Named Arguments (PHP 8.0) reduce the cognitive and runtime overhead of functions with optional parameters. By passing only needed arguments by name, the engine skips default-resolution logic for omitted parameters. In functions with 5+ optional parameters, Named Arguments reduce the opcode count for a typical call by 2–4 opcodes.

Enums

PHP 8.1 Enums replace the common pattern of class constants with a type-safe, OPcache-friendly construct. Backed Enums (int or string) store their value directly in the enum object at compile time. Switching 50 class-constant definitions to Enums in a Domain-Driven Design codebase reduces memory usage per request by an average of 3–5 KB, as measured in Laravel Octane benchmarks.

Readonly Properties and Classes

Readonly Properties (PHP 8.1) and Readonly Classes (PHP 8.2) allow the engine to skip write-lock checks after initialization. In value objects instantiated thousands of times per request — such as DTOs in a CQRS system — readonly enforcement eliminates 1 opcode per property access compared to manually guarded mutable properties.

Which PHP 8.x Version Should You Use for Maximum Performance?

PHP 8.3 delivers the highest performance among all currently supported PHP versions. It combines all cumulative engine optimizations from 8.0 through 8.3 and remains in active support until November 2025, with security support until November 2026.

The decision, however, depends on 3 constraints: framework compatibility, ecosystem package support, and production stability requirements.

New projects in 2024: Use PHP 8.3. All major frameworks — Laravel 11, Symfony 7, WordPress 6.5 — officially support it.
Existing PHP 7.4 projects: Migrate to PHP 8.1 as the minimum target. PHP 8.1 delivers the largest real-world gains (+36.5% over 7.4) and provides Fibers for async workloads.
High-traffic, CPU-intensive applications: Enable JIT Tracing mode (opcache.jit=1254) with a JIT buffer of at least 64 MB (opcache.jit_buffer_size=64M).
I/O-bound web apps: Focus on OPcache preloading and the Inheritance Cache rather than JIT tuning. The measurable gain from JIT on I/O-bound apps is under 10%.
Legacy codebases on shared hosting: PHP 8.2 is the safest upgrade target — it removes deprecated dynamic properties gradually via warnings rather than fatal errors, giving teams time to refactor.

Teams managing Laravel application development should pair PHP 8.3 with Laravel Octane (powered by Swoole or RoadRunner) to persist the application state between requests, eliminating framework bootstrap overhead entirely — reducing average response time from ~30ms to ~3ms on warm Octane workers.

PHP 8.x Performance Benchmarks Across Major Frameworks

Framework benchmarks measure end-to-end HTTP request throughput, not isolated engine speed. The results below use wrk HTTP benchmarking on a local loopback interface to isolate framework overhead from network latency.

All tests run on PHP 8.3 with JIT Tracing enabled, OPcache preloading active, and an empty route handler returning a JSON response.

PHP 8.x Performance Benchmarks Across Major Frameworks

Laravel 11 (PHP 8.3): 1,240 req/sec (FPM) | 18,400 req/sec (Octane + Swoole)
Symfony 7 (PHP 8.3): 2,180 req/sec (FPM) | 22,100 req/sec (Runtime + RoadRunner)
Slim 4 (PHP 8.3): 6,700 req/sec (FPM) — minimal overhead microframework
WordPress 6.5 (PHP 8.3): 147 req/sec (FPM, no object cache) | 890 req/sec (FPM + Redis object cache)
CodeIgniter 4 (PHP 8.3): 4,100 req/sec (FPM)

The data shows that framework architecture — not PHP version alone — determines production throughput. WordPress’s plugin architecture and per-request bootstrap produce 43× fewer requests/sec than Symfony 7 on identical hardware.

Custom web application development on Symfony or Slim captures the full benefit of PHP 8.x engine improvements.

Recommended PHP 8.x INI Configuration for Production Performance

PHP 8.x performance is not automatic — it requires correct php.ini configuration. The following directives activate all major performance subsystems for a production web server:

; OPcache – enable and maximize
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0       ; Set to 1 in development only
opcache.save_comments=1

; JIT – Tracing mode, 128 MB buffer
opcache.jit=1254
opcache.jit_buffer_size=128M

; Preloading (Laravel example)
opcache.preload=/var/www/html/config/preload.php
opcache.preload_user=www-data

; Inheritance Cache (PHP 8.1+)
; Enabled automatically when OPcache is active – no extra directive needed

; PHP-FPM process tuning
pm=dynamic
pm.max_children=50
pm.start_servers=10
pm.min_spare_servers=5
pm.max_spare_servers=20
pm.max_requests=500

Setting opcache.validate_timestamps=0 in production eliminates the file-system stat call PHP makes before every request to check if the source file has changed. This single directive reduces disk I/O per request by 1 system call per included file — in a Laravel application with 300+ autoloaded files, this compounds to significant throughput gains under concurrent load.

PHP 8.x Memory Usage Compared to PHP 7.4

Performance benchmarks measure speed; memory benchmarks determine server density — the number of PHP-FPM workers a given server can sustain.

PHP 8.x reduces peak memory usage per request through 3 mechanisms: readonly property layout optimization, deprecation of dynamic properties, and improvements to the garbage collector’s cycle detection algorithm.

PHP 8.x Memory Usage Compared to PHP 7.4

PHP 7.4 (Laravel 8 request): Peak memory: 14.2 MB per worker
PHP 8.0 (Laravel 9 request): Peak memory: 12.8 MB per worker (−9.9%)
PHP 8.1 (Laravel 10 request): Peak memory: 11.4 MB per worker (−19.7% vs 7.4)
PHP 8.2 (Laravel 10 request): Peak memory: 10.9 MB per worker (−23.2% vs 7.4)
PHP 8.3 (Laravel 11 request): Peak memory: 10.3 MB per worker (−27.5% vs 7.4)

A 27.5% reduction in per-worker memory means a server previously sustaining 50 PHP-FPM workers can sustain 69 workers on PHP 8.3 with the same 1 GB RAM allocation — a 38% increase in request concurrency without adding hardware.

PHP 8.x Support Lifecycle and End-of-Life Dates

Running an end-of-life PHP version eliminates all security patches and therefore disqualifies the server from PCI DSS compliance. The PHP Group publishes a 3-year support window per major version: 2 years of active support plus 1 year of security-only support.

PHP 8.0: End of Life — November 26, 2023. No patches issued after this date.
PHP 8.1: Security support until November 25, 2024. Migrate off by Q4 2024.
PHP 8.2: Active support until December 2024; Security support until December 31, 2025.
PHP 8.3: Active support until November 2025; Security support until November 30, 2026. Current recommended production target.
PHP 8.4 (released November 2024): Introduces Property Hooks and Lazy Objects. Active support until November 2026.

Running PHP 7.4 — which reached End of Life on November 28, 2022 — exposes applications to unpatched CVEs and forfeits all PHP 8.x performance gains. Teams maintaining PHP 7.4 applications on production should treat the migration to PHP 8.3 as a critical infrastructure upgrade, not a feature enhancement.

Final Words

PHP 8.3 is not an incremental update it is a fundamentally faster, more memory-efficient runtime than any previous version.

JIT compilation, OPcache preloading, Fibers, and language-level optimizations collectively deliver up to 48.6% more throughput than PHP 7.4.

Every team still running PHP 7.4 or 8.0 is leaving measurable server capacity and user-facing speed on the table.

Ready to Upgrade Your PHP Application?

Our engineers perform full PHP 8.x migration audits covering JIT configuration, OPcache tuning, codebase compatibility checks, and Laravel Octane deployment with zero downtime.