[HN Gopher] PHP 8.6 Closure Optimizations
___________________________________________________________________
PHP 8.6 Closure Optimizations
Author : moebrowne
Score : 103 points
Date : 2026-04-14 10:59 UTC (2 days ago)
(HTM) web link (wiki.php.net)
(TXT) w3m dump (wiki.php.net)
| moebrowne wrote:
| > 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.
| hyperionultra wrote:
| ~3% performance gains. I didn't understood part about $this.
| rererereferred wrote:
| 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.
| ethan_smith wrote:
| 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.
| kevincox wrote:
| 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.
| eurleif wrote:
| 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
| ragnese wrote:
| 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)
| phplovesong wrote:
| Its bad indeed. Its unfixable at this point. We just get
| bolton features.
| typia wrote:
| Whenever looking at PHP contents, as a lover who has used since
| 1998, cannot find the reason why not to use JS instead.
| pluc wrote:
| Because PHP was designed for this and JS evolved for it. There
| are still JS quirks that should be avoided.
| phplovesong wrote:
| PHP was not designed
| konfusinomicon wrote:
| not designed, it was destined
| Gormo wrote:
| 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.
| Tadpole9181 wrote:
| 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.
| runjake wrote:
| _> 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`.
| chuckadams wrote:
| 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.
| dgb23 wrote:
| 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.
| g8oz wrote:
| 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.
| Meekro wrote:
| 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.
| troupo wrote:
| > 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.
| toast0 wrote:
| > 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
| Meekro wrote:
| 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.
| sidkshatriya wrote:
| > 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.
| mschuster91 wrote:
| > 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_.
| klaussilveira wrote:
| 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
| hparadiz wrote:
| I have a lot more confidence in composer deps versus npm deps
| and it's not even close.
| tail_exchange wrote:
| 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.
| philo23 wrote:
| Little bit of extra detail about static closures in PHP for
| anyone interested:
| https://www.php.net/manual/en/functions.anonymous.php#functi...
___________________________________________________________________
(page generated 2026-04-16 23:00 UTC)