---
title: 'What’s new in PHP 8.5 in terms of performance, debugging and operations'
source: 'https://youtube.com/watch?v=vkqz25e5tM8'
video_id: 'vkqz25e5tM8'
date: 2026-06-14
duration_sec: 1200
---

# What’s new in PHP 8.5 in terms of performance, debugging and operations

> Source: [What’s new in PHP 8.5 in terms of performance, debugging and operations](https://youtube.com/watch?v=vkqz25e5tM8)

## Summary

PHP 8.5 introduces several performance, debugging, and operations improvements. While there are no general speedups, optimizations like opcode specialization for empty array checks and match true statements, a new cURL share init persistent API, and garbage collection improvements for enums and static fake closures can make specific code faster. Opcache is now required and compiled into PHP, and new debugging features include enhanced backtraces for fatal errors and new functions to retrieve error/exception handlers.

### Key Points

- **No general performance improvements** [00:00] — PHP 8.5 does not unconditionally make applications faster than 8.4; a separate benchmark video will be released.
- **Opcode specialization for empty array check** [01:03] — The `$array === []` check is now optimized to be the fastest method, outperforming `empty()`, `!$array`, and `count($array) === 0`.
- **Optimized match true statement** [03:59] — The `match(true)` construct generates optimized opcodes, resulting in 20% faster execution for 1 million iterations.
- **cURL share init persistent API** [05:05] — New API allows sharing DNS, connection, and SSL handshake across PHP requests and processes, reducing latency for third-party API calls.
- **Garbage collection improvements** [07:04] — Enums and static fake closures are no longer considered for cycle collection, reducing GC runs and saving time (e.g., 200ms for 10 million closures).
- **Opcache now required** [09:19] — Opcache is compiled into PHP binary and cannot be disabled; only `opcache.enable=0` can turn it off. This reduces maintenance and errors.
- **Opcache file cache for read-only filesystems** [10:50] — New ini setting allows generating opcache file cache during build step, reducing cold start times by 100-150ms for serverless environments like Bref.
- **PHP_BUILD_PROVIDER constant** [12:36] — A new constant compiled into PHP binary identifies the build provider (e.g., Homebrew, Debian), available at runtime.
- **Debug ini diff flag** [13:46] — The `-d ini=diff` flag outputs only changed ini settings, aiding bug reporting.
- **Max memory limit** [14:27] — New `max_memory_limit` ini setting prevents runtime from increasing memory beyond a set value, enhancing operator control.
- **Memory debugging via environment variable** [15:40] — The `ZEND_MM_DEBUG` environment variable provides additional memory debugging info without recompiling PHP.
- **Stack traces for fatal errors** [17:08] — Fatal errors now include a stack trace when `display_errors` is on, improving debugging.
- **New get_error_handler and get_exception_handler functions** [18:12] — These functions simplify retrieving the current error/exception handlers, with polyfills available for older versions.

### Conclusion

PHP 8.5 brings targeted performance optimizations, operational improvements like required opcache and read-only file cache support, and enhanced debugging capabilities including stack traces for fatal errors and new helper functions.

## Transcript

PHP 8.5 will be released this week and
there's been a lot of work behind the
scenes on performance operations and
debugging related improvements which I
want to highlight in this video. You
cannot usually find these in new release
announcement post or other videos. Mo I
am Benjamin and I'm working on PHP
performance related topics for the past
10 years helping thousands of developers
along the way. If you want to know if
PHP 8.5 is faster than previous versions
of PHP, then I have to disappoint you.
There have been no significant general
improvements to PHP 8.5. So that an
upgrade will unconditionally make your
application faster than running on PHP
8.4. But I will release a video on the
PHP 8.5 performance benchmark and
comparison shortly. So subscribe to this
channel if you haven't yet to get
notified when it's out.
Instead, in this video, I'm going to
focus on changes that make individual
code faster. The first optimization I
want to talk about is an opcode
specialization for the is identical
array statement. What this means is um
in PHP you can write uh a few different
ways to think about comparing if an
array is empty or not. So, uh one way
would be to use the not operator. So say
not a variable. You can say count of the
array is zero. You can use the empty
function and you can use um this way
that is less common where you write the
is identical operator three equals and
then you write the empty uh array
declaration um and compare it to that.
And in PHP 8.4 and previously this was
the slowest way of doing it. You can see
my colleague Tim's benchmark here where
he uh connects the four different ways I
mentioned and empty using the empty um
construct is the fastest one then the
next is using the not operator then
count and the slowest one is using the
is identical statement. So the way it's
written here
and what you can do in the PHP engine is
if there is an op code and you come
across an op code for example the is
identical operator and the op code for
it you can write a specialized handling
if you have c certain conditions that
are true at compile time. So you at
compile time you already know that you
compare something against the empty
array and um uh Tim did that in his
patch. So he identified this case. You
can see here you can use a specialized
handler for the end is identical. And
then here are the conditions that need
to be true. And if that's true then he
writes specialized op code which is much
faster than the general op code for the
is identical operation.
And we are seeing the benefits in the
second benchmark where we see that um
the identical operation is the fastest
one with um the empty and not one being
4% slower and using the count function
being 30% slower. So what this shows is
that using micro optimizations
over time can produce code that is not
even the fastest uh anymore because the
underlying engine changes things in the
functions change. So code changes
through using more modern PHP versions.
And what you can do or should do if like
a certain block of code is not really
critical and in the hot path, just use
the um most readable way of writing code
instead of hunting for always the best
and most fastest uh way of writing
something. The next optimization I want
to talk about is also um optimizing op
codes or generated op codes. This case
in this case for the match true
statement. So if you're using the the
match statement with a true as the
variable. So uh you want to use the
different cases to differentiate which
one is executed. Then uh with this pull
request um and change in PHP 8.5 the
generated op codes from that are
optimized um and this construct will be
faster.
So um you can see um uh Fulkar also my
colleague ran a small benchmark for this
example that um is included in this pull
request where there are four different
uh match statements being executed um in
this match true construct and he showed
that for 1 million iterations
um the new code is 20% faster just by
having a more optimized match construct.
The next optimization in PHP 8.5 is this
new curl share init persistent API that
was included through a RFC. And I've
talked about this in a previous video.
And this is going to have the most
significant impact on applications, but
it requires really that you change your
um the way you communicate with third
party APIs.
Um as you might know, PHP has a shared
nothing memory model. That means nothing
is shared between processes. This
includes if you do calls to third party
APIs, the connection, the DNS resolving
time and the SSL handshake time. And
with the share in it um API for curl,
you can now share this across multiple
PHP requests and uh processes. That
means you can only do the connection and
DNS and SSL handshanking to a third
party host once across the lifetime of
the whole PHP process and then all
subsequent requests will reuse that and
this can mean a lot of time um saved
if the third party API that you're
talking uh to is not really located
close to your uh servers And um once
this is spread across different HTTP
libraries like Gazle and Symfony HTTP
client and they expose this and we are
able to use this across our
applications, we will see a lot of
benefits uh from this change alone in
PHP 8.5. How can you use it? It's a
simple new API curl share in it. you
pass uh one of three constants or all of
them as an array DNS connect and SSL
handshake and then you use this share
resource and pass it to any curl handle
as an option and this automatically
makes this available across requests and
processes and shares this another
performance related change is uh
relating to the garbage collection and
previously in PHP 8.4 four and uh lower
versions if you used enums or static fay
closures then they were not specifically
marked as um that they are not using
cycles. So by definition an enum is not
pointing to another object and also a
static fake closure is not doing that.
So they can never be actually garbage
collected by the cycle collector because
when they're present they are still used
there's no cycle they cannot be
collected so checking if they should be
collected is already wasteful and with
this change by Ilia they are not
considered um for the cycle collection
anymore and this either makes the
garbage collection trigger much later
because you're using a lot of enums and
static factor closures or um it makes it
faster because it's not considering
these um additional objects that cannot
be collected by the garbage collection.
Anyways,
so um you can see in this pull request
here in the old way um for this example
code for 10 million static fake closures
um the garbage collection runs 44 times.
Application runtime is 1.8. 8 seconds
and after this change garbage collection
doesn't run at all anymore and
application time is 1.6 seconds. So 200
milliseconds are saved uh by this
optimization not wastefully running the
garbage collector.
So one thing you might ask yourself is
what is a static fake closure? And in
this example you can see using this um
uh splat operator here the um to create
a closure from a function call um is
considered a st stat static fake closure
in the engine and there's also another
way to generate it using the closure
from callable function on reflection
closure from callable and um uh also a
few other ways of creating static fake
closures. Another change in PHP 8.5 is
that opcache is now a required
extension. It's a required part of PHP.
You cannot disable it anymore. That also
means opcache is not a shared object
anymore. It's compiled into the PHP
binary. And the only way to not have the
opache cache something is to use any
directives. OPC cache enable um to zero.
And uh for CLI scripts, opcache enable
CLI had to be enabled and still has to
be enabled explicitly to enable opcache.
The benefit of this change is that the
optimizer of the engine and the
optimizations that happen in opcache can
now more easily interact with each
other. It might be easier to write this
code. It might be easier to move some
code from op uh from the opcache
extensions into the engine. It will
reduce the maintenance cost and it will
also reduce a source of errors. For
example, it's still necessary in the
official Docker PHP images to explicitly
enable Docker and if you forget that
then uh your Docker containers will not
contain Docker at all uh op um cache at
all. And this is a performance problem
that we see occasionally from with
customers using docker and kubernetus
for example where their application is
not using op uh cache at all because
they forgot to include that in their php
container. Another op uh cache related
change is uh also going to be making
docker container users
uh lambda users for example through bre
or through laravel um uh happy because
there's now a way to generate the
opcache file cache. So generating the
opcache optimizations during a build
step into files and then uh specifying
that the file system of the running
applicant
that um with a readonly file system you
couldn't use the the the file cache of
opcache because it would just um perform
uh delete operations and crash the
process lead to errors and stuff. So
this is now possible using an through an
uh any setting you can specify that the
file system of the cache is read only
and this will uh make it possible to use
it with breath. For example,
you can see in the pull request also
that the breath author Matthew Napoli um
responded to this change and tested this
and he saw um the cold start time of a
container reduce by 100 to 150
milliseconds um by using this and you
can see his blog post uh on the topic.
Uh I think this is a great thing uh um
for these kind of deployment scenarios
and I hope to see like uh these kind of
big of improvements benefiting uh the
whole community. Another operations
related change is the introduction of
the u PHP build provider constant. This
constant is now compiled into the PHP
binary if the um an if the environment
variable PHP build provider is set
during the compilation step. And this
allows um a build provider for PHP to
specify who they are. Gives some more
context and the community already would
work into individual build providers
setting this. So, homebrew, dbian,
fedora and the official docker images
will set this value. You have this
constant in PHP code available in this
case. So, it's defined. You can echo it.
And this information was already shown
in the PHP info output and in the PHP-
version output um of the binary and now
is available at runtime. Another um
change in PHP 8.5 is also reg uh
regarding debugging capabilities. Um it
will be especially helpful when
providing error reports to the PHP
projects or to open source projects. um
you can specify this um d-ini
equals diff um flag to the php binary
and it will output all the ini settings
that have changed compared to the
default values. So it will only output
the changed variables.
And with this information, you can um uh
attach it to a a buck report or
something like that. And then a
contributor can more easily see what you
changed compared to the defaults. And it
will make it much easier to uh to figure
out the changes that potentially are
causing problems um for maintainers.
before PHP 8.5 um the memory limit uh
variable that you can specify in PHP INI
could always be overwritten at runtime
by writing some code uh writing any set
memory limit increasing it to 2 GB 4 GB
whatever high value you want. However,
in certain scenarios, the operator of a
system may want to restrict uh and dis
disallow the runtime to increase the
memory indefinitely. And this is now uh
possible in PHP 8.5. You can specify a
maximum memory uh limit that um the
runtime cannot increase above. So if you
set the max memory limit for example to
200 mgabytes, runtime can never change
it to be higher. If you try to attempt
to set it higher then it will set it to
the max memory limit and um this is
giving additional safety to operators of
PHP and um preventing developers of the
system to increase the memory um across
certain or above certain allowed limits.
If you had memory related problems in
PHP itself, crashes, uh anything related
to the memory allocation, it was quite
difficult to find these bugs without
like recompiling PHP, adding additional
memory protections, attaching a debugger
um that allows this. All of this was
quite difficult uh before and uh we at
Tideways uh shipping a PHP extension to
thirdparty people our customers using
tideways sometimes if there's a problem
in memory it was very hard debugging
this with this change in PHP 8.4 four
that are no addit. Um there's actually a
way to increase the output um and have
some additional memory debugging
information just by setting an
environment variable to the already
compiled PHP binary. You can see in his
pull request description the zen mm
debug environment variable can get a
bunch of different information here and
with that you get additional debugging
capabilities. And if you run like across
a memory related sack fault in your PHP
on production um you now have some
additional capabilities of finding out
why this happens. Arguably this is very
advanced however like it will help
across the community. another RFC that
uh went into PHP 8.5 uh um improves
debugging capabilities and it's um a new
like an improvement to how back traces
work with fatal errors or at least sort
of now they are rendered with fatal
errors. Previously, if you ran a PHP
script and it uh ran into a fatal error,
then there was actually no stack trace
printed um with that error. So, if
you're running a script on the CLI, for
example, a fatal error occurred, maximum
execution time of 1 second reached, you
wouldn't have know like where this
happened. And with PHP 8.5, we now
automatically see the text stack trace
attached to that. And this is also tied
into the display error setting. So when
you set display errors to on, you will
see this. When it's to off, you won't
see it. Uh so it's some additional
information that helps you debug in your
development system. When you show
errors, um you will be able to see where
they happened. The last change is also
related to error handling and it's the
introduction of two new functions, get
error handler and get exception handler.
It was previously possible to get access
to these through some obscure way of
using restore and set handler but it was
not obvious to like new users of PHP how
they are able to obtain u the reference
to the current error and uh exception
handler and with these two new functions
it's now easier to write this kind of
code there's are polyfills available to
use it in lower versions but with PHP
8.5 five, you can now rely on these
functions to be available and uh it's
easier to write more complex um error
handling and exception handling code uh
using those two functions.
I hope you can see there are some really
great additions to PHP performance to uh
operations and to debugging capabilities
in PHP 8.5. I'm really excited about it.
I'm also quite proud that uh my
colleagues Tim and Fulkar did a lot of
work on this release. Tim did like quite
a few changes and Fula will be the
release master of the 8.4 um branch and
we as Tideways sort of like contributed
to this version in this big regard. I
hope uh that you find these changes
interesting as well um and that you find
they are a great addition um on top of
the new features that PHP 8.5 will
include. If you're interested in
additional videos about PHP performance
related topics, please subscribe to this
channel or subscribe to the newsletter
that is linked in the description as
well. We and we will get in touch with
you when something new is coming up.
Bye.