PHP 8.6 Closure Optimizations
wiki.php.net
PHP 8.6 Closure Optimizations
1–10 of 53 posts
Re: PHP 8.6 Closure Optimizations
#2> 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.
Re: PHP 8.6 Closure Optimizations
#3~3% performance gains. I didn’t understood part about $this.
Re: PHP 8.6 Closure Optimizations
#4It 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.
Re: PHP 8.6 Closure Optimizations
#5~3% performance gains. I didn’t understood part about $this.
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.
Re: PHP 8.6 Closure Optimizations
#6[deleted]
Re: PHP 8.6 Closure Optimizations
#7Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.
Re: PHP 8.6 Closure Optimizations
#8Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.
Because PHP was designed for this and JS evolved for it. There are still JS quirks that should be avoided.
Re: PHP 8.6 Closure Optimizations
#9It 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 coll…
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 implementationRe: PHP 8.6 Closure Optimizations
#10Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.
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.