5 ms·

PHP 8.6 Closure Optimizations

124 points by moebrowne 6mo ago

hyperionultra 6mo ago
~3% performance gains. I didn’t understood part about $this.
- rererereferred 6mo 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.
- ethan_smith 6mo 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.
moebrowne 6mo 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.
kevincox 6mo 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.
- eurleif 6mo 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
  - ragnese 6mo 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)
    - phplovesong 6mo ago
      Its bad indeed. Its unfixable at this point. We just get bolton features.
      - hajile 6mo ago
        We could do something like `#function() {}` or `#() => {}` which makes a function static.
    - tialaramex 6mo 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?"
      - cardanome 6mo 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.
deleted 6mo ago
[deleted]
typia 6mo ago
Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.
- hparadiz 6mo ago
  I have a lot more confidence in composer deps versus npm deps and it's not even close.
  - jamesfinlayson 6mo 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.
- pluc 6mo ago
  Because PHP was designed for this and JS evolved for it. There are still JS quirks that should be avoided.
  - phplovesong 6mo ago
    PHP was not designed
    - konfusinomicon 6mo ago
      not designed, it was destined
      - phplovesong 6mo ago
        It was just a really good timing. The web 1.0 was just getting popular. And now 30 years later, we still suffer from this "timing". Luckily there is so many better alternatives in 2026.
- Gormo 6mo 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.
philo23 6mo ago
Little bit of extra detail about static closures in PHP for anyone interested: https://www.php.net/manual/en/functions.anonymous.php#functions.anonymous-functions.static https://www.php.net/manual/en/functions.anonymous.php#functi...

124 points by moebrowne 6mo ago

hyperionultra 6mo ago

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

rererereferred 6mo 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.
ethan_smith 6mo 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.

moebrowne 6mo 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.

kevincox 6mo 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.

eurleif 6mo 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
- ragnese 6mo 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)
  - phplovesong 6mo ago
    Its bad indeed. Its unfixable at this point. We just get bolton features.
    - hajile 6mo ago
      We could do something like `#function() {}` or `#() => {}` which makes a function static.
  - tialaramex 6mo 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?"
    - cardanome 6mo 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.

deleted 6mo ago

[deleted]

typia 6mo ago

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

hparadiz 6mo ago
I have a lot more confidence in composer deps versus npm deps and it's not even close.
- jamesfinlayson 6mo 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.
pluc 6mo ago
Because PHP was designed for this and JS evolved for it. There are still JS quirks that should be avoided.
- phplovesong 6mo ago
  PHP was not designed
  - konfusinomicon 6mo ago
    not designed, it was destined
    - phplovesong 6mo ago
      It was just a really good timing. The web 1.0 was just getting popular. And now 30 years later, we still suffer from this "timing". Luckily there is so many better alternatives in 2026.
Gormo 6mo 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.

philo23 6mo ago

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