PHP 8.5 Performance Reality Check: What Benchmarks Show and Where the Wins Really Come From

PHP 8.5 Performance Reality Check: What Benchmarks Show and Where the Wins Really Come From

Every PHP release comes with a round of benchmarks showing dramatic percentage improvements on synthetic workloads. PHP 8.5 is no different. The headline numbers look impressive. The reality for your application is more complicated, and the places where you actually gain performance are not always the places the benchmark posts suggest.

This article breaks down where PHP 8.5 performance improvements actually come from, why the popular benchmarks mislead, and how to measure the real impact on your own application.

Why Synthetic Benchmarks Mislead

The benchmarks you see shared most often run tight loops: millions of function calls, array operations, string manipulations, mathematical computations. These benchmarks exercise the engine internals intensively, which means they amplify small improvements in the runtime into dramatic percentage gains.

A benchmark that runs array_map over ten million elements in a loop will show a measurable improvement if the engine shaves a nanosecond off each internal call dispatch. That improvement is real. But your application does not call array_map ten million times per request. It calls it a few dozen times, interleaved with database queries that take milliseconds, template rendering that allocates memory, and I/O operations that dwarf any engine-level optimisation.

The typical PHP web request spends its time roughly like this:

  • 40 to 60 percent waiting on database queries and external services
  • 10 to 20 percent in framework bootstrapping and routing
  • 10 to 15 percent in template rendering
  • 5 to 15 percent in actual application logic
  • 5 to 10 percent in autoloading and class resolution

A 15 percent improvement in the engine’s raw computation speed applies to maybe 5 to 15 percent of your request time. The net result is a 1 to 2 percent improvement on the total request, which is real but nowhere near the headline number.

This does not mean the benchmarks are lying. It means they measure something different from what your application does.

Where the Real Gains Come From

PHP 8.5 ships improvements across several areas. Their impact on real applications varies.

JIT Improvements

The JIT compiler continues to mature with each release. PHP 8.5 includes better type inference for compiled code paths, reduced compilation overhead for short-lived functions, and improved register allocation on x86-64.

For most web applications, the JIT remains a marginal contributor. The request lifecycle in a typical PHP application is too short and too I/O-bound for JIT compilation to pay off. The compilation cost per function only justifies itself when that function runs thousands of times within a single request, which is uncommon in web workloads.

Where JIT does help:

  • Long-running CLI processes. Queue workers, data import scripts, and background jobs that run for minutes or hours in a single process benefit meaningfully. The compilation cost amortises across thousands of iterations.
  • Computation-heavy request paths. PDF generation, image processing, report calculations, or anything that loops heavily over data within a single request.
  • Applications using opcache.jit_buffer_size correctly. Setting this too low causes partial compilation and wasted overhead. Setting it too high wastes shared memory. For most applications, 64M to 128M is a reasonable starting point.

If your application is a standard CRUD web app with database queries, form handling, and template rendering, the JIT probably gives you less than 1 percent on total request time. Turning it off entirely might even save a small amount of memory overhead.

Internal Function Optimisations

PHP 8.5 includes micro-optimisations to frequently called internal functions: faster array_key_exists, improved isset on nested arrays, and reduced overhead in sprintf and implode. These are genuine improvements, but they accumulate slowly across a request because each individual call saves microseconds.

Where this adds up: applications that do heavy data transformation within PHP. If you are processing CSV imports, transforming API responses, or building complex report data structures, the internal function optimisations contribute a measurable improvement. For typical page renders, the effect is negligible.

OPcache Improvements

This is where legacy applications typically see the most impact, and it gets the least attention in benchmark posts.

PHP 8.5 includes improvements to OPcache’s memory management, better handling of large class hierarchies in the shared memory cache, and reduced OPcache invalidation overhead during deploys. For applications with thousands of classes, such as those built on Zend Framework or Laminas MVC, OPcache handles the compiled bytecode more efficiently.

The OPcache interned strings buffer also benefits from better deduplication in 8.5. Large applications that load hundreds of files per request see reduced memory pressure from repeated string storage.

If you have not already tuned your OPcache configuration, doing so will give you a bigger improvement than the PHP version upgrade itself. The PHP Performance Playbook covers OPcache tuning in detail, and the Performance Optimisation for Zend Framework Applications chapter covers the framework-specific considerations.

Preloading Maturity

OPcache preloading, introduced in PHP 7.4, has received incremental stability fixes in every release since. PHP 8.5 improves error handling when preloading fails and provides better diagnostic output when class dependencies cannot be resolved during the preload phase. This does not change the performance ceiling, but it makes preloading more practical to deploy in large applications where dependency ordering has historically caused failures.

What Legacy Apps Specifically Gain

Legacy applications on Zend Framework or Laminas MVC tend to have specific performance profiles: large class counts, deep inheritance hierarchies, significant autoloading overhead, and heavy use of reflection and service manager factories.

For these applications, the performance gains from PHP 8.5 come primarily from:

  1. OPcache handling large class maps more efficiently. If your application loads 500 or more classes per request, the OPcache improvements reduce memory overhead per request.
  2. Reduced autoloading overhead when combined with Composer’s classmap authoritative mode. PHP 8.5’s improved file_exists and is_file internal performance slightly reduces the cost of autoloader misses, but the real gain comes from eliminating filesystem lookups entirely through classmap authoritative mode.
  3. Better garbage collection for short-lived objects. Legacy applications that create and discard many small objects (view models, form elements, hydrator instances) benefit from the improved GC cycle detection in 8.5.

The cumulative effect on a legacy Laminas MVC application is typically 3 to 8 percent faster response times compared to PHP 8.4, with most of the gain coming from OPcache and memory management rather than JIT or raw computation speed.

If you are planning the PHP 8.5 upgrade, the PHP 8.5 Upgrade Checklist for Legacy Apps covers the compatibility steps, and the PHP 8.4 Upgrade Notes for Older Codebases covers the deprecation issues from the previous version that you should resolve first.

How to Measure Real Performance in Your Application

Stop relying on other people’s benchmarks. Measure your own application. Here is a methodology that produces actionable numbers.

Step 1: Establish a Baseline

Run your application on its current PHP version under realistic load. You need:

  • A representative request set. Not just the homepage. Include your most common pages, your heaviest pages (reports, search results, admin dashboards), and your API endpoints.
  • A load testing tool that replays real traffic patterns. A tool like wrk, k6, or siege with a script that mimics actual user behaviour. Single-URL benchmarks are as misleading as synthetic benchmarks.
  • Application-level metrics. Total request time, database query time, memory peak usage. Instrument these with your APM tool or with manual timing at the application boundaries.

Record the p50, p95, and p99 response times. Averages hide the variance that matters.

Step 2: Upgrade PHP and Change Nothing Else

Deploy the new PHP version to a staging environment that matches production. Same hardware, same database, same dataset. Change only the PHP version. Do not tune OPcache, do not enable new features, do not refactor code.

Run the same benchmark suite. Compare the numbers.

This isolates the engine improvement from any other change. The difference is what PHP 8.5 gives you for free.

Step 3: Tune OPcache

Now adjust OPcache settings for the new version. Key settings to revisit:

1
2
3
4
5
6
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.jit_buffer_size=64M
opcache.jit=tracing

Set validate_timestamps=0 in production and use a deploy hook to clear OPcache. This avoids the per-request stat call on every cached file.

Run the benchmark again. The difference between step 2 and step 3 is what OPcache tuning gives you.

Step 4: Measure Preloading (Optional)

If you have not tried OPcache preloading, add a preload script that loads your most frequently used classes. Measure again. For large applications, this can be the single biggest win, often more significant than the PHP version change itself.

Step 5: Profile the Outliers

Look at your p99 response times. The slowest requests are where optimisation has the most impact. Profile those specific request paths with Xdebug or SPX to identify whether the bottleneck is in PHP execution, database queries, or I/O.

The Numbers That Actually Matter

For a typical legacy PHP application upgrading from 8.4 to 8.5:

  • Raw engine speed improvement: 2 to 5 percent on CPU-bound code paths
  • OPcache improvement for large class hierarchies: 3 to 8 percent reduction in memory and time
  • JIT impact on web requests: 0 to 2 percent (higher for computation-heavy paths)
  • OPcache preloading (if not already enabled): 5 to 15 percent on total request time
  • Autoloader optimisation (if not already done): 3 to 10 percent on bootstrap time

The lesson is consistent across PHP versions: infrastructure-level optimisations (OPcache config, preloading, autoloader classmap, connection pooling) deliver more than engine-level improvements. A well-tuned PHP 8.4 application will outperform a poorly-tuned PHP 8.5 application every time.

Upgrade for the security patches and deprecation runway. Tune OPcache for the performance. Do not upgrade expecting the engine alone to solve performance problems that live in your database queries, your N+1 loops, or your unoptimised autoloader.

The PHP Performance Playbook provides the full tuning methodology, and the Working with Legacy PHP Codebases article covers the broader strategy for improving legacy application health beyond raw performance numbers.