PHP 8.6 Closure Optimizations

Posted by moebrowne 3 days ago

Counter119Comment43OpenOriginal

Comments

Comment by kevincox 1 day ago

It is an interesting comparison that JavaScript always ensures that different evaluations of a closure expression results in unique instances. So in general the closures will require allocations for each (unless the allocation is otherwise prevented such as via escape analysis). Of course much of the underlying data may be shared, but the identity itself will be unique.

I don't know how strict JavaScript garbage collection rules are. This was non-observable for the longest time but FinalizationRegistry now exists which makes cleanup observable. It sounds like basically no guarantees are provided when an object will be cleaned up, so presumably an implementation would be allowed to make optimizations such are proposed where for PHP.

Comment by eurleif 22 hours ago

The part that would violate guarantees in JavaScript is not function objects being kept alive longer, but function objects which should be distinct not being so.

    function foo() {
        return function() { };
    }
    console.log(foo() === foo()); // This must log `false` in a compliant implementation

Comment by ragnese 19 hours ago

This is also a problem, IMO, in having this optimization in PHP. Anonymous functions are instances of a Closure class, which means that the `===` operator should return false for `foo() === foo()` just like it would for `new MyClass() === new MyClass()`.

But, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP all the time and it's still a terrible language even in 2026)

Comment by tialaramex 15 hours ago

I never understood why people think somehow PHP is fine now, and I've had that opinion expressed several times on HN. The best I can make out is that people's expectations are so dismal now that they're like "Well new versions fixed 2 of the 5 worst problems I noticed, so that's good right?"

Comment by cardanome 14 hours ago

Because PHP is a amazing backed language for making CRUD apps. Always has been.

It has great web frameworks, a good gradual typing story and is the easiest language to deploy.

You can start with simple shared hosting, copy your files into the server and you are done. No docker, nothing.

Sure it has warts but so have all mainstream programming languages. I find it more pleasant than TypeScript which suffers from long compile times and a crazy complex type system.

The only downside is that PHP as a job means lots of legacy code. It a solid career but you will rarely if ever have interesting programming projects.

Comment by phplovesong 17 hours ago

Its bad indeed. Its unfixable at this point. We just get bolton features.

Comment by hajile 10 hours ago

We could do something like `#function() {}` or `#() => {}` which makes a function static.

Comment by user3939382 7 hours ago

It’s a “terrible” language? That’s news to me. What’s “terrible” about it?

> `new MyClass() === new MyClass()`

Does that look like the code you’re writing for some reason? Because I’ve seen 100k loc enterprise PHP apps that not once ran into that as an issue. The closest would be entities in an ORM for which there were other features for this anyway.

Comment by philo23 20 hours ago

Little bit of extra detail about static closures in PHP for anyone interested: https://www.php.net/manual/en/functions.anonymous.php#functi...

Comment by moebrowne 3 days ago

> Non-static closures are turned into static ones if they are guaranteed not to make use of $this.

> Stateless closures, i.e. those that are static, don't capture any variables and don't declare any static variables, are cached between uses.

Comment by hyperionultra 1 day ago

~3% performance gains. I didn’t understood part about $this.

Comment by rererereferred 1 day ago

If the closure doesn't use $this (an instance of the current class) then it doesn't need to store a reference to it, which also skips the bookkeeping from the garbage collector.

Comment by ethan_smith 19 hours ago

In PHP, closures defined inside a class method automatically capture `$this`, which means the closure holds a reference to the entire object even if it never uses it. This prevents the object from being garbage collected and adds overhead. The optimization detects when `$this` isn't actually used and makes the closure static automatically, dropping that unnecessary reference.

Comment by 1 day ago

Comment by typia 22 hours ago

Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.

Comment by Gormo 22 hours ago

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead.

PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to still have interpreted code at the end), native and full-featured object orientation, generally better runtime performance, and a package ecosystem with Composer that isn't overrun with inane vanity projects and supply-chain vulnerabilities.

The only major downside to PHP is that it's not great at multithreading, but if you're building microservices where parallelization is handled by an external orchestrator, then you can design around that pretty effectively.

Comment by bakkoting 12 hours ago

> type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to still have interpreted code at the end)

All major server-side JS runtimes are capable of executing TypeScript without transpilation these days. Complex build processes are only really a thing for client-side JS. The normal state of affairs these days is to run server-side code with no build step whatsoever.

Comment by Gormo 11 hours ago

That's true to some extent, but working with many modern frameworks often still requires a build step. Next.js in particular has quite a heavy toolchain.

Comment by dgb23 19 hours ago

PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request. Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

Comment by Meekro 19 hours ago

There are advantages to the lack of application state, though. Memory leaks and similar bugs became largely irrelevant, for instance. Regarding performance, a simple LAMP stack on a dedicated machine can easily give you <250ms pageloads for many web apps. If that's not fast enough, or you're averaging dozens or hundreds of requests per second, you're probably big enough that you can use parallelization or more exotic architectures to speed things up.

Comment by toast0 16 hours ago

> PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request.

Sure, in PHP, the reality is that after your request is processed, all the state is garbage and is thrown out. But once you embrace that reality and stop trying to make sculpture from garbage, you can make some pretty damn fast pages that get straight to the point. Of course, a lot of people look at my fast PHP and say that it too is garbage, but at least it's fast garbage :P

Comment by 9dev 7 hours ago

That ceased to be true a while ago since the ecosystem gravitated towards FrankenPHP, a stateful application server written in Go as a Caddy module. The performance is amazing, the Go Bridge allows easy extension, and it’s rock solid.

Comment by g8oz 19 hours ago

I agree that PHP's request oriented "shared nothing" approach has its advantages.

That being said there are very decent options for long running processes/application servers these days - see RoadRunner, Swoole and Frankenphp.

Comment by troupo 16 hours ago

> because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request.

Where "application" is basically a single page with less code than a typical React page. Even 20 years ago you'd run into DB struggling to give you data fast enough before you hit any issues with the "re-running the entire app".

And you have to screw your database really badly to see any issues early. Hell, phpBB was horrendously bad, running dozens of heavy DB queries on each page, and was still powering some of the internet's busiest forums.

> Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

Yes. It is an enormous advantage: it's fire and forget. You don't need to "SSR" your app (getting all data and state), ship it to the client with a bundle, then "re-hydrate" it (once again pulling data and state from the server) etc.

Comment by Meekro 19 hours ago

It's true that the lack of multithreading in PHP has been a persistent pain. I love PHP and I've done PHP-centric projects for 20 years, but I end up falling back to Go when it's time to write a background worker that will handle lots of tasks in parallel. I really wish my PHP apps could include native components that process background tasks in parallel.

On the other hand, Javascript's parallelization is one of the hardest-to-understand things I've ever seen: in order to really grasp the async/await model, you have to know the whole story of callback hell and how modern Javascript papers over it while carefully preserving backwards compatibility.

Comment by sidkshatriya 18 hours ago

> It's true that the lack of multithreading in PHP has been a persistent pain.

No actually it's a joy to have no multithreading. It keeps the complexity budget lower. You can do multithreading through a custom PHP module if you had a very specific need. Maybe my requirements were too simple but I've never really felt the need. The shared nothing PHP architecture really helps you get away with this.

Anyways as the parent comment said:

> but if you're building microservices where parallelization is handled by an external orchestrator, then you can design around that pretty effectively.

Comment by martinald 14 hours ago

I feel like I'm on a different planet when I see this kind of comment.

What if you need to call multiple external APIs at once with complex json? Sure you can call them one after another, but if each take (say) 2s to return (not uncommon IME), then you are in real trouble with only one thread - even if it is just for one "request".

I guess I'm spoilt in .NET with Task.WhenAll which makes it trivial to do this kind of stuff.

Comment by theodorejb 14 hours ago

This can be done with curl_multi_exec(), or with $client->getAsync() in Guzzle.

https://www.php.net/manual/en/function.curl-multi-exec.php

https://docs.guzzlephp.org/en/stable/quickstart.html#concurr...

Comment by Gormo 11 hours ago

ReactPHP is another good option.

Comment by Gormo 11 hours ago

> What if you need to call multiple external APIs at once with complex json?

A few years ago, I had a PHP project that had grown by accretion from taking a single complex input and triggering 2-3 external endpoints to eventually making calls to about 15 sequentially. Processing a single submission went from taking 5-10 seconds to over five minutes.

This was readily solved by moving to ReactPHP (https://reactphp.org/), which implements async via event loops. I was able to reduce the 15 sequential external API calls to four sequential loops (which was the minimum number due to path dependencies in the sequence of operations). That reduced the five minutes back to an average of 20-30 seconds for the complete process.

It wasn't using true multithreading, but in a situation where most of the time was just waiting for responses from remote servers, an event loop solution is usually more than sufficient.

Comment by mschuster91 18 hours ago

> It's true that the lack of multithreading in PHP has been a persistent pain.

That's... not necessarily a bad thing to lack. Entire classes of bugs that are common in Java, C/C++, .NET and other true multi-threaded environments simply cannot exist in the PHP world at all.

Comment by sellmesoap 9 hours ago

I think frankenphp checks a lot of boxes here, go to handle the threads with php built in https://frankenphp.dev/

Comment by Tadpole9181 20 hours ago

As someone who prefers PHP in general and find the TC39 committee has kneecapped the JS language in the past few years...

> PHP has a vastly simpler toolchain

Firmly disagree.

You can install Node and have a basic server running in a few seconds.

PHP requires installing and setting up a server tied into FPM and then reconfiguring a slurry of bad defaults. If you don't avoid the footgun of "traditional" deployments, you get to deal with mixed versions of source. If you don't avoid the footgun of "native" sessions, you get to deal with INCOMPLETE_CLASS errors galore.

And if you want a dynamic frontend, you're still going to want to bust out JS.

> I can't find any reason why I wouldn't use PHP instead

Using a single language for both frontend and backend with (largely) the same availability of tooling and the ability to share code (i.e. type definitions).

> generally better runtime performance

I find this hard to believe? Intuitively, I would assume that the Node / Bun engines are significantly faster than PHP - which doesn't even come with it's JIT enabled by default on the (perfectly valid) note that backends are almost always constrained by DB times.

> a package ecosystem with Composer that isn't overrun with inane vanity projects and supply-chain vulnerabilities.

Functionally, Composer is worse than any of the NPM package managers IMO. PHP's global, shared namespaces preventing monkey patching and nested dependencies is a huge burden when you need to use Lib A and Lib B, but both have conflicting dependencies on Lib C.

But the only reason it doesn't suffer (as many) supply chain issues is two-fold:

1. Packagist's source of truth is the repo and tags. It's much easier to notice a Github account being compromised, which is already harder because it's always had better account security expectations, than NPM. But this comes at costs - such as being unable to rename a package in-place, because Composer gets really confused when it clones a trunk that has a different name than what you asked for. And it's not intrinsically more secure, since tags are not immutable and people can host on less secure VCS platforms.

2. But more than that... it's just less used? The PHP ecosystem is noticeably smaller and has way less happening.

So its very much trade-offs.

Comment by runjake 20 hours ago

> You can install Node and have a basic server running in a few seconds. PHP requires installing and setting up a server tied into FPM...

Without mentioning more, the PHP equivalent to your Node example is `php -S`.

Comment by chuckadams 18 hours ago

Or FrankenPHP, or hell, there's still even good old Apache. Or avoid the SAPI interface entirely with servers in PHP like Workerman, AMPHP, or Swoole. FPM is entirely too fussy for me to bother with: its error handling is atrocious (restarting in an infinite loop with no backoff is common), and no one really knows how to tune it.

Comment by Gormo 11 hours ago

Those are great solutions for production deployment, but to the previous commenter's point, for iterating on your local machine during development work, nothing beats just running `php -S`.

Launch the interpreter's built-in dev server in your project directory, load up localhost in your browser, work on your code, and testing incremental changes locally is just a matter of hitting F5.

Comment by archerx 9 hours ago

I’ve been using PHP for over a decade and have never used FPM.

“Using a single language for both frontend and backend with (largely) the same availability of tooling and the ability to share code”

Is a negative I went backend world and front end world to be different because they do very very different things.

“But more than that... it's just less used? The PHP ecosystem is noticeably smaller and has way less happening.”

That’s not true, PHP is less resume driven development and actually about productivity. I’m really happy narcissist hate PHP and don’t burden it with their garbage and slopworks.

Comment by klaussilveira 21 hours ago

I have a few:

- Batteries included, everything you need out of the box. No need to npm install left-pad

- Optional, per-file strict types, without the need to transpile from another language

- No need to build anything, lightning fast scripting language

- Is its own HTML templating language (or XML), no need for JSX

- No supply-chain fiascos, stable and mature ecosystem

Comment by hparadiz 20 hours ago

I have a lot more confidence in composer deps versus npm deps and it's not even close.

Comment by jamesfinlayson 9 hours ago

Huge agree. I think I've nuked vendor/ a handful of times in 8 years of doing PHP while I've lost track of the number of times I've deleted node_modules/ this year alone.

Comment by pluc 22 hours ago

Because PHP was designed for this and JS evolved for it. There are still JS quirks that should be avoided.

Comment by phplovesong 17 hours ago

PHP was not designed

Comment by konfusinomicon 15 hours ago

not designed, it was destined

Comment by tail_exchange 17 hours ago

For greenfield projects, I agree. It gets the job done, but PHP would never be my choice for a new project. Bun seems like a much better choice in pretty much every criteria.