PHP 8.5 with JIT: Does It Really Make Your Code Faster? (2026 Benchmark)

PHP 8.0 introduced the JIT (Just‑In‑Time) compilation engine, a feature that promised to push PHP performance closer to compiled languages. With PHP 8.5 now the latest stable branch, JIT has matured and is enabled by default in many hosting environments. But the question remains: how much real‑world speedup does JIT actually deliver?

In our previous benchmark, we compared PHP 8.3, 8.4, and 8.5 with JIT disabled to isolate core engine improvements. This time, we take the best performer – PHP 8.5.2 – and run it head‑to‑head: JIT enabled vs. JIT disabled.

We use the exact same CPU‑intensive script (Fibonacci + 1M loop iterations) to see how much of a difference JIT makes. All tests are reproducible, and you’ll find the full scripts at the end.

note：The server was restarted between the two test series (JIT off / JIT on) to clear any caches.

Methodology

1. Test script – The same CPU‑heavy script was used for both JIT off and JIT on runs:

• Recursive Fibonacci up to fibonacci(35) (≈ 18 million function calls).
• 1,000,000 iterations of mathematical operations (sqrt() and sin()).
• The script outputs only a fixed string "OK" to guarantee identical response lengths for ab.

1. Memory measurement – Peak memory usage was captured with memory_get_peak_usage(true) and written to a log file after each request.
2. Each JIT setting was tested with five independent runs of 1000 requests each.
3. For every metric, the highest and lowest values were discarded, and the remaining three were averaged.
4. Concurrency was kept at 1 to measure pure CPU performance without process‑pool contention.

Results

Below are the raw numbers from five consecutive runs for each JIT configuration. The final averages (after removing min and max) are used for comparison.

Table 1: JIT Disabled vs Enabled – Raw Data

*Each cell shows Requests per second followed by average response time in ms (higher req/s and lower response time are better).*

Table 2: Key Metrics Comparison

*Memory values are approximate and may vary slightly between runs.*

Analysis

The data speaks clearly:

• Throughput jump: Enabling JIT (tracing mode) increased requests per second by over 110% (from 1.76 to 3.71). For CPU‑bound workloads, this is a massive boost.
• Latency drop: Average response time fell by more than 52% (from 568 ms to 270 ms), meaning each request finishes in less than half the time.
• Memory unchanged: Peak memory usage stayed at 2 MB, showing that JIT introduces no measurable memory overhead in this test – an excellent trade‑off.
• Stability: The low standard deviation across runs (especially for JIT enabled) confirms the consistency of the test environment and the maturity of the JIT compiler.

These improvements far exceed typical expectations: our script, with its deep recursion and heavy loops, is the perfect candidate for JIT optimisation. In fact, enabling JIT more than doubled the throughput – a result that will surprise many developers accustomed to modest 5‑10% gains.

Should You Enable JIT in Production?

The answer depends on your application profile – and our benchmark provides a clear reference point.

JIT is a massive win if your application is CPU‑bound

Examples include image processing, PDF generation, complex calculations, data analysis, and long‑running background jobs.

Our test shows a 110% throughput increase and 52% lower latency with JIT enabled. If your code does serious number‑crunching, you can expect gains in this ballpark – potentially doubling performance with zero extra memory cost.

For typical web applications (WordPress, Laravel, etc.)

Most web requests are I/O‑bound – waiting for databases, files, or external APIs. Here, CPU is rarely the bottleneck, so JIT’s impact is usually smaller (often 1‑5%).

However, JIT rarely hurts performance, and it can still help with background tasks (e.g., cron jobs, queue workers). Our recommendation: enable it, but don’t expect miracles – and always measure.

Things to watch out for

• Memory: JIT reserves a buffer (jit_buffer_size). The default 128M is fine for most sites, but on memory‑constrained hosts you may want to lower it.
• Compatibility: JIT works with all standard PHP code, but some very old extensions might not be aware of it. Test in a staging environment first.
• Real‑world variance: Your mileage will vary. Our 110% gain came from an ideal CPU‑heavy script – real applications mix I/O and CPU, so results will differ. Always benchmark your own workload.

Conclusion

• PHP 8.5 with JIT enabled delivers a game‑changing performance boost for CPU‑heavy workloads – in our tests, throughput more than doubled and response time was cut in half.
• Memory overhead is zero, making this optimisation essentially free.
• For any application with significant CPU‑bound tasks, enabling JIT is no longer just “nice to have” – it’s a must.

Frequently Asked Questions

Test Scripts (for Reproducibility)

Important: Run these commands only on your own isolated test server. Never load‑test a production site.

PHP Benchmark Script (test.php)

<?php
set_time_limit(0);
function fibonacci($n) {
    if ($n <= 1) return $n;
    return fibonacci($n-1) + fibonacci($n-2);
}
function loopTest($iterations) {
    $result = 0;
    for ($i = 0; $i < $iterations; $i++) {
        $result += sqrt($i) * sin($i);
    }
    return $result;
}
fibonacci(35);
loopTest(1000000);
// Optional: log memory peak
$memoryPeak = memory_get_peak_usage(true);
file_put_contents('/tmp/php85_jit_memory.log', date('Y-m-d H:i:s') . " - Memory peak: " . round($memoryPeak / 1024 / 1024, 2) . " MB\n", FILE_APPEND);
echo "OK";
?>

Apache Bench Commands

# Test JIT disabled (after configuring JIT=disable)
ab -n 1000 -c 1 https://phpbenchlab.com:8083/test.php
# Test JIT enabled (after configuring JIT=tracing)
ab -n 1000 -c 1 https://phpbenchlab.com:8083/test.php

This test focused on pure CPU workloads. We later extended this JIT analysis to test its impact under heavy I/O latency. The PHP 8.5 JIT I/O latency benchmark reveals that JIT provides zero benefit—and sometimes a penalty—for slow database queries across all four application servers.

All raw data and scripts are provided. Feel free to reproduce this benchmark on your own hardware.