---
title: 'PHP Performance Demystified: Internals, Profiling, and the Road to PHP 9 with Volker Dusch'
source: 'https://youtube.com/watch?v=PYhuj7E16Js'
video_id: 'PYhuj7E16Js'
date: 2026-06-22
duration_sec: 2352
---

# PHP Performance Demystified: Internals, Profiling, and the Road to PHP 9 with Volker Dusch

> Source: [PHP Performance Demystified: Internals, Profiling, and the Road to PHP 9 with Volker Dusch](https://youtube.com/watch?v=PYhuj7E16Js)

## Summary

In this interview, Volker Dusch, a PHP release manager and co-founder of Tideways, discusses PHP performance optimization. He explains how understanding the PHP engine's internals can help developers write faster code and debunks the myth that PHP is inherently slow. The conversation also covers his role as release manager for PHP 8.5 and the future of the language, including the path to PHP 9.

### Key Points

- **Talk Overview** [00:11] — Volker's talk will cover how the PHP engine works internally, how to measure performance externally, and how to develop intuition for performance issues.
- **Profiling Tools** [01:30] — He will show how to use open-source profilers to see every function call and understand what's happening in PHP without changing code.
- **Real-World Performance Issue** [02:48] — An e-commerce shop had a plugin that fetched a tracking token on every page load, adding 1.5 seconds per request, even though the token never changed.
- **PHP vs Other Languages** [03:52] — PHP is not inherently slow; it depends on the use case. For web applications, PHP holds up well against JavaScript, Python, and Ruby.
- **Rewrite Fallacy** [05:13] — Rewriting in a new language is often faster because you re-evaluate decisions, not because of the language itself.
- **Doctrine 3 Upgrade Issue** [07:00] — After upgrading Doctrine 3, Tideways' software became five times slower because custom optimizations didn't apply to the new version.
- **Tideways Overview** [10:46] — Tideways is an APM tool that focuses exclusively on PHP, automatically instrumenting code via a PHP extension without requiring manual changes.
- **PHP 8.5 Release Manager** [16:00] — Volker is one of the two release managers for PHP 8.5, a role that involves coordination and decision-making rather than complex engineering.
- **Path to PHP 9** [26:42] — The upgrade path to PHP 9 is expected to be smoother than past major version jumps, thanks to lessons learned from previous migrations.

## Transcript

Vular, welcome. You're going to be
talking about performance in PHP. What
exactly will you be telling us all about
at PHP UK conference?
>> Hey, thank you. Nice to to be here. Um,
so the main thing I want to I want to
talk about to people is how does the PHP
engine actually work and how do you make
decisions based on that. So not just uh
and we'll also be talking about that not
but not how just how to measure the
program externally but also to develop a
better intuition and understanding of
how these things work so that when you
look at a piece of code you can also
already make some guesses about the PHP
side of the performance and then we're
also going to talk about the usual
performance aspects like how do I
measure how long the database is taking
and we'll we'll see some other
approaches like most people probably
have seen how to instrument this in in
userland like you make a wrapper around
your database calls and you and and and
you do that. But I want to show some
more um seale approaches, some more PHP
extensions you can use in some more
low-level tooling to really figure out
what's going on without having to
necessarily change the code. For
example, if you have a problem that only
happens in production,
>> I see. So if people come along and if
they have uh slow running code or code
that you know doesn't seem to be
performing as well as they would expect
then the takeaway from your talk will be
one of the takeaways from your talk will
be here's how we can measure it and
here's will will actually show how to
make changes um based on that
information.
>> Um so what I will be showing is a bit
how to work with a profiler. There's a
couple great open source tools out there
where you can like run a request or run
a process and really see every single
function call that happens or see like a
couple thousand times a second what's
what's going on in in in PHP and then
how this looks after you make a change
but also just how to like reason about
performance and how PHP actually
executes your code internally so you get
a better understanding for what's going
on there as well.
>> Amazing. And in your work, have you
applied these principles on projects
that you've been working on? And what's
been your biggest performance increase
based on this the kind of work the kind
of analysis you do?
>> So like there's always a couple fun
stories to tell, but so um I work for
for a company um we'll maybe talk about
that a bit later. I'm not going to go
into much detail where we help other
other people with performance problems
both in a consulting fashion but mostly
in providing a a software as a service
platform to them where they can improve
their code and like there is there is
like the the hard winds of people like
hey I have this service it has like a 7
millisecond response time we want to get
it down to five like what what can we do
what can we measure and those are like
very intricate and very specific but
then there is also like here's an
e-commerce shop and they had installed a
plugin that uh every for every single
page uh page load that they make like
wants to get like a a token for like
some tracking service and that just
takes one and a half seconds. Uh and
it's just like every single request and
that token never changes and they could
just have it in there but that plug-in
just like fetches it for every single
page request. And um because it's like a
big e-commerce shop with a bunch of
plugins that you haven't written,
debugging that can actually be quite
annoying. So like people can use our
tool or other tools to like get that
information very quickly and so that was
a great great experience with the
customer of like their onboarding to the
product and the first thing was like oh
that's the problem and within minutes
you have a solution and it's it's really
fun to see like
>> how how fast you can make PHP and what
you can get out of the language while
still having like a nice highle language
that allows you to work very quickly uh
but then still get really good
performance out of it as well.
So the PHP haters who say it's too slow,
that's not really true, is it? I mean,
it I it always depends on like for what
use case and what you want to do with
it. um like uh if if if you need a
real-time application or like if you
want to do high frequency trading
wherever you would want to do that like
I probably wouldn't do that in PHP and
um but uh for a website and like if we
if we compare PHP to other web languages
like JavaScript, Python, Ruby um I'll go
a bit in the talk about like some
comparisons there as well but I think
PHP holds up really really well And um
given the given how core works and the
and the improvements there and how the
engine works, there are some things that
PHP is really good at. Like it also
checks your types at runtime. So you
don't like if you get a JSON response
from an endpoint that you didn't expect,
it won't magically do the wrong thing
because the types didn't match because
it actually checks the types. And that's
cool. And it still manages to outperform
some of the languages that don't do
that. So I think there is there's a lot
to be said for running PHP.
I see. So if people are watching this
and maybe they've got a slow web
application or e-commerce thing and
they're thinking, do we need to change
from PHP to another language? The answer
would probably be well actually let's
look at the performance of our PHP
application first. And
>> yes,
>> I I I think it's not like usually like
uh if you rewrite something in a new
language, it's not faster because you've
used another language, but it's faster
because you rewritten the whole thing.
Um, and the the process of like
re-evaluating all your decisions and
reing your approaches and like redoing
that usually helps more. And so chances
are if you're good at one language and
you do it again in that language, you
actually end up with a way better result
than if you move to a new language where
you don't know all the pitfalls and all
the potential issues that are coming
with that.
>> [gasps]
>> But yes, but I suppose that a far a far
lower effort or engineering effort is to
use some of the things you're going to
talk about and maybe some of the tools
that you're going to talk about in this
talk and that will probably illuminate
some of the uh some of the issues you
might be having uh with with with
performance.
>> Yes indeed.
And have you have you on on well you
might not want to answer this but on
projects you've worked on have you had a
really embarrassing uh find where you
suddenly gone oh my goodness this is the
reason it's it's it's so slow.
>> Um like yes like so due to due to the
nature of our product like we we get
thousands of requests per second with
with customer data um that that we use.
So like we have some some endpoints that
are rather performance critical and um I
mean I wouldn't necessarily like say
embarrassing. That's just uh the nature
of working in a in a small self-owned
company without like billions of startup
money where you do stuff and then you
see in production if it works and
especially if you work on a tool that
helps people run their software in
production, measure it in production, it
also makes sense that we use our own
tool to look at our own software. So one
of the things um that we did was the the
doctrine 3 upgrade and um my boss
Benjamin is also one of the core people
of the doctrine project and we upgraded
that and then during that process we
learned that a couple of the custom
things that we've done around doctrine
to make it faster didn't fully apply to
the new version. So like after the
upgrade things were quite a bit slower.
Uh and it was really fun to see like
like we we made the deployment and then
our software told us like hey the thing
is five times slower now and it's like
ah cool um like that is like one of the
normal stories where you know you're
doing something but also over the years
there is a bunch of stuff where we where
we looked at something I was like
not sure why we're looping over this
thing every time to find an element here
like this is a very long list uh like
this is really like some PHP level thing
where like it's a million elements in an
array and like we're looping through it
to find something and uh we have so many
hashmaps in PHP. This might actually be
one of the good use cases for that.
Let's let's do that. and then like yeah
seconds of that stuff goes away or like
you're not clearing some some um or m
cache or something and that means the
thing has to loop through a lot of stuff
and it's quite fun to see when when
using a tool that shows you like all the
function calls that a process makes and
then it's like
>> string leng 50 million it's like ah that
seems a bit off
[laughter and gasps]
maybe we shouldn't be doing that.
>> Wow. So when you look at these things, a
lot of the some of the things just jump
out almost immediately, do they? Oh,
well, that's something to investigate.
There's some inner loop we're going
around millions of times. And
>> yeah, I mean, that's the that's the fun
moments when you when you open it up and
you immediately find something. But the
other the other fun part I think of
performance work is also like buckling
down with a problem for an hour or two
or uh longer and using a tool and like
really looking at like the individual
steps and where the time is spent and
trying to make something like trying to
make something 10% faster usually that
is already fast is a lot harder than
trying to make something a lot faster
that when when when there is like these
obvious errors. So it's both of these
things can be fun. Yeah, I've certainly
had some embarrassing uh performance
related uh problems on on projects. Uh
one of them we were running is ages ago
we had a like a Jenkins box for for CI
>> and the test suite took 45 minutes to
run and back then we were using Garrett
so every single commit had to had to go
through validation and there were bits
where we would leave it on in the
evening and come in the next day and it
was still running. And we're like, "Oh,
we've got to get these tests down." And
then somebody looked at the
configuration. They said, "Why have you
got XD debug running on the Jenkins
thing and they like flicked the flag and
suddenly the test went from like 45
minutes down to 15." I [laughter] mean,
it was it was like I spent three days
trying to speed it up prior to that. So,
that was super embarrassing that it was
just something as simple as a as a flag.
But uh [laughter]
>> it's a good one.
>> Yeah. Yeah. These these things happen.
Um yeah and and you actually so tell me
a bit more about Tideways because you're
one of the sponsors for the conference
and it's quite related to what you're
talking about. So what does Tideways do
if people have never heard of them and
>> Yes. So
>> engage
>> yeah we're super happy to sponsor the
conference like after you've accepted my
talk we we talked internally and like if
I'm if I'm going there and if you're so
nice to invite me actually we might as
well sponsor. Um, so we're a a small
company from Germany um with um that
focuses exclusively on on PHP and we're
an APM like you might know data do or
Sentry or other products. Um, and what
we're doing and what what our core focus
is is that we exclusively focus on PHP
on on making you not write all your
instrumentation code yourself or
installing a bunch of libraries or like
doing a lot of the upfront work to get
performance insights. But what we want
to achieve with with what Tideway is
doing is that you can on board with us
and you immediately get meaningful
insights because the PHP extension that
we have auto automatically instruments
your code for you and you don't have to
do anything except install that
extension and then you already get
insights um that um and the product is
like split in in in three main things.
So we have a monitoring product where
you can see your performance over time
and you see if something gets slower. Um
we have error like all the error
tracking things um that uh we instrument
like all the error handlers of major
frameworks and grab the errors from
there and um everything that you would
expect to to see if your application is
healthy. And then we also have like a
tracing and profiling thing where you
can like with um
xh or xdebug or php spx would be some
open source tools to mention. Um and
with tideways like you can go to your
own website click a button and then you
see every function call that happens on
that page and like how long it took and
how everything is structured. But we
also have like a low low overhead mode
where we grab the most important bits of
your application and so you have
continuously like oh someone said the
website was slow and you don't have to
then start looking at it but you can
look back at the data that's already
collected and see if it's slow. Yeah.
And yeah
>> I see. So so what we would do if you
were using your product is you would
just install something on your
production server and it would collect
all this data in
not a very intrusive way.
>> And then and then how do you view it
all? Is that do you go to the tidalist
website to view it all or does all that
data?
>> Okay. So all the data gets all the
relevant data gets transferred and you
can you can view it.
>> Exactly. So the way this works is you
install our PHP extension and after the
PHP request is done um that data then
gets sent to a local thing running on
your server um that's written in in Go
where we do a lot of sanitization stuff
because we don't want to have your
customers email addresses. We don't want
to have any private information. We
don't want to see the strings in your
SQL queries like this is all stuff that
you don't want us to see and that we
don't want to have. Um so that gets all
stripped out on your system and then
sent to us where we aggregate it, show
you charts, generate alerts um for like
we have like a big database of known
problems of things that are slow or like
of configuration issues and stuff like
that. So it al also checks your systems
configuration. Um or it says like hey
you're running like a magenta juice shop
and you you're running into this known
problem. Um here is like how to fix
that. And so you don't have to you don't
even have to spend the time of figuring
out what the problem is. You can just
use like our observations and our
learning to do that. And then on top of
that you get like the continuous
monitoring to see if something um yeah
uh gets gets worse in the in the future.
I see. So you can set up what alerts as
well. So if things start to slow down
then you get alerts say well look this
used to be really quick and now it's now
it's not so quick. Yes, like we can have
you can set you can send us when you
make a release and then you get a
release comparison for like did it get
better or slower? Are there more errors?
Like you can get you get all the error
monitoring and things you would expect
from like a a monitoring solution. But
we tried to be like a an affordable like
a really affordable one piece package
where you maybe you don't get like the
full insight that you would get with
data dog but that you also don't need a
full operations team to look at it and
really try to be a solution for people
that don't have massive engineering
teams. Um, while also allowing people
that do performance the whole day to
give them the tools with the tracing and
the deep insights that they don't have
to like set this up on every developer
machine and they can use our tools and
do that do local testing and do testing
in production for performance. Yes. And
we do this with with a with a small team
um with Benjamin, me and a couple
colleagues of mine, one of whom is a PHP
core contributor that I'm very happy
that Tide is sponsoring some time to
work on PHP. Um I do some work on PH for
PHP as well and like it's it's very nice
that we're also able to give back given
like our exclusive focus on PHP. Of
course, we also have a vested interest
in the language. Um but with with the
Sentry open source pledge like we also
support that fully and give to the PHP
Foundation. I think we're like one of
the bigger contributors there and the
funding member. Uh so yeah that that
make that that makes it really nice to
to work as part of the ecosystem there
while still like providing a product
that uh allows us to to pay people.
[snorts]
>> Yeah. Nice. And I suppose actually
you've you've um referred to the fact
you do things for the PHP language, but
you've actually been you actually the
release manager, aren't you, for
>> Yes. So for PHP 8.5, I'm one of the two
release managers together with uh Daniel
Shhatzer from from the from the States.
Um we we put out the 85 release that has
uh released with the do.0 in November
and now we we get to do all the dot
versions. Yeah, that was a lot of fun as
well and learning and getting to know
more of the core people and getting to
know more about how PHP works internally
after being on the mailing list for many
years and doing small things like my my
colleague um Tim also has helped me to
write a couple PHP RFC. So there's like
four or five small language features
that I had a hand in. Like I do write
some C but I'm not extremely fluent in
PHP core. Like I did m maintain our
extension before we found him who does a
way smoother job at it. And I'm very
happy that that we have him as well uh
with with deep PHP engine knowledge like
we also managed to make our own
instrumentation a bit faster and have
some fun there. Yeah.
And so I suppose yeah that does work
quite well you know getting involved
with the core of it and doing what you
do for your for your day job. But how on
earth did you or what made you think oh
I want to be a PHP 8.5 release manager?
Um, so when it like when the
announcement was made that that they're
looking for new people, I think only two
or three people put their name up for
for a vote. And I thought um
like it it would be nice if there would
be just a couple more uh people
volunteering for these types of things
because it's not like it's not that much
uh uh work but it's also something that
that needs to be done and people should
have a choice there um in in how they
want who they want to have doing that.
So, I put my name up for that and
apparently um the the internalist
community or the people that are allowed
to vote on these things um for having
contributed to PHP in the past decided
that they would also like me to do that.
Um yeah, and it was I I think it was a
nice way to to give back um to PHP in a
way that doesn't require like extensive
C knowledge.
>> Um I see like Oh, so you don't you don't
need to be wellversed in C to be the
release manager then.
like it it it helps to be able to read
it and um to to be able to judge like
pull requests, but even that I would say
is optional um like you learn some
things along the way and of course like
having a strong PHP background also
helps but there is not a ton of
decisions that you need to make and the
great thing is that you have all the um
all the great people from from the core
team you have all the foundation people
to talk to and they're very responsive
and very nice and like everyone has a
vested interest uh in the fact that the
next PHP release is as great as the last
one. So, um people are also very willing
to help and like it's more of a like
going around making sure everyone is
happy, all the check boxes are checked
and everything is going according to
plan and smoothly than it is to like do
very complicated engineering work. Uh so
I think it's something more people could
consider if they if they like want to
give back to to to the PHP project in
that way.
>> Yeah. And and if anyone is uh coming to
the PHP UK conference and they want to
find out more presumably that you're
happy to talk to them in the in the
hallway track.
>> Absolutely. Like um I'm I'm happy to to
walk people through how the RFC process
work like how you can contribute
features to PHP, how you can propose
feature ideas like in
I think around the time of the
conference at a bit later we will have
the voting on um the next uh release
manager for for 8.6. I think that
process will start soon
um as the release is coming out in
November and there's like a 3 months I
don't know uh I don't know from the top
of my head period before that will start
with the voting quite soon. So uh yeah
if someone's interested in that and
wants to hear like the the experience of
that which is very positive but I'm
happy to go into more detail there in
person. Yeah come come find me talk to
me.
>> Brilliant. And and how much effort does
it take? I assume a lot of it is within
the final three months before the
release or
>> yes same throughout the year.
>> The the great thing about having two
people do that is that um basically
every release is done by one person and
then you're off for the next one. So um
there is a there is a bit more of a time
commitment in the um in the time leading
up to that where we have around 10
releases if everything goes well. So
like four alpha releases, couple beta
releases, a couple RC's, and then the
release candidates are like the the more
engaging phase where you make the most
of the decisions as a release manager
like which which feature still fits in
the new next release, which feature
needs to wait a bit because it's
changing too many things or it's
breaking stuff um and figuring figuring
these things out. Um, but
I say it's a rather manageable time
commitment. Like now going forward for
the next two years, I think like it's a
Tuesday and a Thursday like a couple
hours on on a Tuesday and uh an hour on
a Thursday every month like once every
month. So this is that's quite okay. And
before that it's a bit more involved.
Um, but it's definitely not uh something
that you need to take time off from uh
from your day job for to to do that.
Especially if you work in a PHP company
and this is like something you can talk
to them about. It's like, hey, is it
cool if I do this for a couple hours uh
a month?
>> Yeah. Well, thank you very much for all
your efforts uh for because it's a great
release 8.5.
>> Thank you for putting up a conference.
[laughter]
>> That's right. Um I I because I actually
that's that's another thing you talk
about releases like people some people
might just think oh it's just the big
November release but actually there's
lots of like patch releases throughout
throughout the year. Is is there is it
just when something needs doing or did
you try and keep it at regular
intervals? So this is kept on a regular
interval and as a the release manager
yourself you don't have to do a lot
there because the people that work on
core and work on um like assume like
let's say there's a bug fix like some
some some someone from from the PHP
source team um will identify like in
which version does that bug fix need to
go into and they will make sure it lands
in all the right branches. Um, and then
you just come by and package all of that
up and they probably have already taken
care of the news uh as well. So like all
you need to do is like look in the news
file that's in the repository and then
you already have your change log ready.
Um so most of that work is done there
and the um
the more involved bits are more uh
decision- making than like running
running around and figuring that out
just because the people who who work on
PHP source are so diligent in in what
they do and are so easy to work with.
>> Sure. So I suppose in terms of uh
deciding which features go in does that
mean there might be an RFC which has
been approved and all the work has been
done but due to the nature of the
changes you might say oh we're not going
to put this in 8.5 we'll have to wait
till 8.6. Is it those kind of decisions
you need to make or does every RFC
that's complete in time actually make it
in?
>> Everything that is completed in time
makes it in. So it's not like um as a
release manager you can say like oh that
thing that's already in we're not going
to release that uh because that's
already in. But there is a there is a
couple months time period where um you
get to voice your opinions and um
potentially reject changes that like oh
we already released a couple alphas,
people already started testing and now
we want to make this like big
fundamental change that is just a bit
too much or a bit too dangerous or like
someone has to make the call on like is
this really a bug fix? Is this a
feature? Is this a refactoring that is
really necessary now? like what's the
what's the benefit of doing this now
versus doing that later. But yeah, all
the work that has that has been done or
that's going on during the year will um
just be released. Let's go with that.
And thankfully like everyone that's
contributing to to core also seem like
all the all the bugs I've seen all the
problems I've seen are usually like just
picked up by the people who um worked on
that area because they all like want to
have the stuff that they care about look
good and work well. Um so it's it's it's
not a lot of like you don't really have
to run after people to get stuff figured
out.
>> Yeah.
>> And I expect you get this question a
lot. Who decides that the next release
was 8.6 and not version 9? How's that
decision made?
>> I think there isn't like a single person
that decides that. Um
my understanding is that this like
making the new version a major version
just needs an RFC. So it basically needs
like someone to say, "Hey, we should
make the next version the the 90
version." Um I think this is more of a
natural thing of people coming together
and being like oh like we have all these
deprecations we maybe maybe we have like
a really killer feature around the
corner or like there's a big refactoring
that we like someone has made like a
great change but that is easier if we
could clean up some of PHP's past uh and
where the the people that work on on
source come together and say like now it
feels like a good time. Um, so like I
know there has been some discussion if
there should be an 86 or if there should
be a 9. There's like maybe there is some
marketing consideration, maybe there is
some consideration of like we don't want
to pile up all these deprecations and
like do we already have a super clear
migration path? How did the last release
go?
>> Yeah. So it it it's more of a community
effort in that sense that just a lot of
people discuss this and if it feels like
the time is right, someone will make a
proposal and then it's voted on.
I see. And you largely are trying to get
all the breaking changes
uh just in like major releases.
Is that the Yeah. Yeah. I mean
[clears throat]
>> minor breaking things in the in the in
the you know
>> Yeah. I mean some sometimes there's like
a bug fix in in an external library that
you could consider a breaking change and
how it processes stuff, but that is also
like technically the right thing it
should be doing and a behavior people
don't rely on. But like I think PHP has
learned a lot from um 53 to 7 and or
like when when seven came up like and
then 56 I think was it and then we went
to seven but like that wasn't an easy
migration. Four to five wasn't an easy
migration for people. I think um the
industry took some lessons for there and
then Python 2 to Python 3 reinforced
those lessons as well with like there is
a bunch of stuff that where people say
like oh this looks a bit nicer but it
just means you have to touch every every
file of code that you have and it's not
really a tangible benefit and I think
the people that work on PHP have a good
sense of how much of the internet is run
by PHP and how how important that
language is for the health of the web
also like being a language that isn't
funded by like one big company like
there is no single organization that
runs PHP or pays for it or does a lot of
stuff like if you look at um the open
collective page like there is
a bunch of companies but but none of
them has has has like a major share in
the contribution and there is not like
there isn't like a company that hire I
don't think there is any company that
hire employs more than two maybe three
PHP core people
>> and like those are not full-time either.
>> Um I'm sure there is a company uh and
I'm I'm I'm sorry for that but like just
from the contributions that I'm seeing
like this is a lot of the stuff comes
from the PHP Foundation. Um, and it's
not like there is something like with
Golang where you have a billion dollar
investment from one of the tech giants
or something with TypeScript or
JavaScript that big companies have an
interest in owning the egg ecosystem to
to to sell stuff. Um so yeah this works
a bit different for for PHP I think and
um that freedom also is quite nice
because everyone that works on that
really works works on it because they
want to make it better and they want to
contribute to it and not for oh like I'm
just paid to do this like it's really
nice attitudes of everyone.
Yeah, it's always seems a really nice uh
community, you know, when and every time
you speak to people like the they're
always really friendly and helpful. So,
it's it's it's always good, I think.
Yeah.
>> And then from and then from the adaption
that we're seeing like with our
customers and hideways, there is of
course still people who run seven and I
hope they do that on on plans that where
you still get external support for PHP.
Um I think there is still a couple
companies like with with tideways itself
we still support PHP 72 or 73
um like we we do support PHP 5 as well
like we just don't change our um tooling
um for that much anymore and um some
things still work but I'm not seeing a
lot of five out there um I think those
projects are uh not being actively
worked on um and more in in a in a very
maintenance state But um especially for
e-commerce which is also a chunk of the
people that that work with us um 74 we
still see some um and I think that's
just the natural the natural way of
having a language such a long and
storied history and that has provided so
much value that there is so much stuff
out there that also just works um where
I think security and uh is is more of
the the reasons we eventually upgrade
than anything else.
M so that when we do eventually go to
version 9 that pathway should be easier
for people than say 5 to 7 or 7 to8 that
that's that's kind of the hope is it
>> I mean it is it I think that has always
been the hope um I think we we can also
make this a reality this time like um I
think the the next um like all that if
if you have a code base on 85 without
seeing a lot of deprecations. And from
what I'm seeing, like we do collect
deprecation information from all of the
people that run Tideways if they
activate that feature. Um, it's looking
quite good. Like there isn't a lot of
like core stuff that that gets people.
Um, I think if you run a mostly
deprecationfree thing by either like
looking at your logs or having a tool
like like tideways or using some other
way to to track that, then the upgrade
to 9 should be rather painless from what
I'm seeing now. But of course there will
might also be a reason why we switch to
nine to to change some other stuff. Um
but I think like I said like everyone in
that that works on core is quite aware
of the of the impact of that and uh I
think one of the important parts to
realize about the PHP community is also
that it is a lot of smaller communities
that all don't talk so much to one
another like WordPress is a big thing
Drupal is a big thing is a big thing
Laravel is a big thing and like all of
these like communities exchange ideas
but they also all do things a bit in
their own way do these things a bit
different and I don't think there is
like the one right way to to to write
PHP which is also the challenge for core
like that you can't say like oh like
here we here's a feature that should
that make makes only sense if you do
functional programming I think
personally is something that really
doesn't fit into PHP uh because like
everything that the the core language
has should serve all of these
communities and like of course there is
some APIs in PHP that are like only
object-oriented um and that's something
that has the language has built around.
But like it it managed to stay rather
generic to serve all of these different
needs. And given that all of these
communities also do provide feedback in
their own way with for example Symfony
and PHPUnit being really great at
integrating against the current version
like the the master the the master or
main branch of the PHP repository. Uh
and then you get feedback very early
like when we broke something during the
the first uh or second alpha release
like I I was talking to the folks from
composer about like hey like the symfony
install broke this broke because of
composer this broke because of this
thing that like actually I put into PHP
and then we got that fixed in a day uh
just by having these like very quick
feedback cycles. Uh and that's really
cool.
Yeah, I suppose it's really good that
you do have these people kind of running
really at the bleeding edge just to feed
back those those kind of issues. And I
imagine also like the whole all of the
tech stack is is getting a lot more
mature. Like you've got really good
static analysis. You've got tools like
recctor to help people upgrade from one
version to the next. So I I kind of
imagine that um and actually I think
people are doing a lot more testing. You
know, you've got PHPUnit, you've got
pest, I suppose. I suppose that does
mean that when people upgrade, you know,
if they've at least got a test suite,
you know, it can act as some kind of
smoke test what what you know the what's
going on in PHP. Uh so I suspect if all
of those practices improve and people
take uh you take up all of these tooling
then that does mean that your feedback
will be will be a lot quicker I suppose.
>> Absolutely. Yes. Like I think there is
like the people you talked about now I
think mostly are like application
developers that work on more custom
applications. Then there is of course
like a big chunk of the ecosystem is
people running software written in PHP
is people running Drupal is people
running Shopware um or or other things.
And for them they like they upgrade when
the hostet tells them to upgrade or they
update when um
>> they they run out of security support
for a thing hopefully. and um or they
update because the new version has like
performance benefits that they've heard
about and they want to see that or to
get rid of a bug or something like this
is usually what motivates or they just
like have a well organized IT setup
where they just want to be on current
versions for like to to be protected uh
always and to to manage their
infrastructure. And like these are two
very different feedbacks that you get
from from people who can fix their own
bugs or from people that are dependent
on vendors to to do stuff. Um but of
course uh you get more detailed and more
frequent feedback of course from the
people who actually like develop these
applications than you get from the
people who run them.
>> Yeah. Yeah. And sometimes you know you
see the I don't know sometimes I learn
about language features you know when
you have this what's new in PHP the
latest version and then normally at the
end of those talks people have a whole
series deprecations and stuff they've
been removed and often I learn about
language features at the point they're
being removed because they just seem
some of them just seem absolutely crazy
that they they existed in the first
place and I imagine uh if you're quite
conservative about your PHP usage and
you stick to like uh like just the
fundamental main bits, then you're
probably going to be okay on the
upgrades really. I can never really
remember having any difficulty on a a
PHP version upgrade, you know. say even
from 7 to 8 and 5 to 7.
>> I think one of the one of the more
frustrating things for um for that
ecosystem is of course you you mostly
hear from the most vocal people that
struggle maybe with a tiny thing that um
would take 5 minutes to fix and takes
hours to complain about. Um but uh that
is just people who might like have a lot
of stuff to do on their job and now that
also happened and now that is really
annoying to them but it's actually not a
big change. They might just not be very
familiar with with with what they're
doing there or they might not stay up to
date. So thinking about these people and
being respectful of their time I think
is as important as people who like come
to PHP with an issue and say this broke
something also being respectful and like
the easiest way to to make sure that
your stuff works is of course to test it
before we make a new release because
then we can discuss that and change
things. Uh but yeah just due to the
nature and the age of PHP there is a a
lot of stuff in there like I think PHP
has always um over the years like been a
language where if you had a very
specific problem especially like in the
in the earlier like 2 three four days
like you could put that in PHP and you
had like your very specific solution to
your very specific problem and now like
the standard library is not changing as
much like new things like the um the new
random extension or the the URI passer
or something are built into their own
name spaces so they fit like very well
with um with the rest of the ecosystem
but uh the the real core functions
aren't touched so much because it's just
hard to not break people's things
>> um and like also for people who want to
now put features in PHP like come from
very different backgrounds in how they
write applications and like what they
want to do and um I think over the years
PHP has adapted features from all other
programming languages. Um, and like
sometimes there I feel like there's a
checklist of like, oh, this language has
a feature like with a syntax that
doesn't fit in PHP. Can we cram that in
as well? Um, as a bit of a joke, of
course, but like people get inspired by
a lot of stuff and are like, why doesn't
PHP have that? And because the language
is so welcoming to to changes, um, a lot
of that stuff then happens. So, uh, I
think it's quite fun to see like all the
little bits and pieces coming coming
together.
>> Yeah. Yeah. Well, I found this really
interesting actually just finding out
what happens uh I suppose from the
release manager point and how the
language is um put together and and all
the additional constraints that you have
to work with things that perhaps most
developers don't think about because
they just think about their own you know
sphere of knowledge they know about. So,
uh, thank you very much for all the work
you do on we've done and for getting PHP
8.5 out. Uh, I'm looking forward to your
talk at, uh, PHP UK conference, uh,
which is on the February the 20th, uh,
of, uh, 2026 in London. Um, so I look
forward to to seeing you there and thank
you for having this taking this time for
this chat.
>> Very excited to be there and, uh, yeah,
looking forward to it and thank you very
much. That was a great conversation, a
lot of fun.