Static & global function first-class callables shouldn't be reallocated every time they're hit (possible performance optimisation)

[dktapps]

Description

As per title. This makes first-class callables slower than legacy, ugly callables.

Consider the following example:

function dummy() : void{

}

function encodeToString(callable $writerFunc) : void{
	$writerFunc();
}

$loops = 100000000;

$start = hrtime(true);
for($i = 0; $i < $loops; $i++) {
	encodeToString('dummy');
}
echo "legacy callable: " . number_format((hrtime(true) - $start) / $loops, 2) . "ns\n";

$start = hrtime(true);
for($i = 0; $i < $loops; $i++) {
	encodeToString(dummy(...));
}
echo "1c callable inline: " . number_format((hrtime(true) - $start) / $loops, 2) . "ns\n";

$start = hrtime(true);
$writerFunc = dummy(...);
for($i = 0; $i < $loops; $i++) {
	encodeToString($writerFunc);
}
echo "1c callable outside loop: " . number_format((hrtime(true) - $start) / $loops, 2) . "ns\n";

In PHP 8.4, this gives the following results:

legacy callable: 45.16ns
1c callable inline: 64.63ns
1c callable outside loop: 40.14ns

To my knowledge, there is no good reason why a first-class callable of a global or static method should be reallocated every time these loop statements are executed. They have no lexical scope dependency - don't need any local vars, have no $this, etc.

My gut feeling is that these types of dependency-free 1cc should be able to be treated similarly to literals and constants.

As an aside: This is something that's also been bothering me about the new pipe operator in 8.5. I don't know how the underlying implementation works, but if it doesn't get optimised down to simple function calls at compile time, then pipe code using first-class callables will be quite a bit slower than nested function calls on account of all the closure reallocations.

PHP Version

PHP 8.4.12 (cli) (built: Sep  7 2025 21:40:54) (ZTS Visual C++ 2022 x64)
Copyright (c) The PHP Group
Zend Engine v4.4.12, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.12, Copyright (c), by Zend Technologies

Operating System

Windows 11

[mvorisek]

Great repro, the 3rd case shows the function is not compiled and the 1st shows even old fashioned dynamic function lookup is fast/faster.

I did some more testing and even static fn () => 1 (replacing dummy(...) in 2nd case) is slow, so this is not solely related to first class callable.

To even more suprise, the times are not improved /w opcache (tested using 3v4l.org).

[dktapps]

True. I hadn't considered static closures. I suppose anything with no $this, no use(), and no static variables should be reusable.

[iluuu1994]

I created a PoC here: #19863

$ php-84 test.php
legacy callable: 29.03ns
1c callable inline: 53.82ns
1c callable outside loop: 22.06ns

$ php-dev test.php
legacy callable: 25.24ns
1c callable inline: 25.59ns
1c callable outside loop: 20.82ns

There's still a small overhead due to cache lookup, which is unavoidable.

In terms of static closures, this should also be possible with a similar approach when the closure has no bound values or static variables. In that case, it's effectively stateless and may be shared. Luckily, Closure::bindTo() returns a copy of the closure, rather than modifying the closure itself. Hard to say how common static closures with no bound values are, probably not too common.

[dktapps]

Hard to say how common static closures with no bound values are, probably not too common.

If it wasn't for auto-binding $this even when it's not used, they'd probably be a lot more common even if not explicitly declared. I know it's needed for stuff like self:: and parent:: in dynamic context, but it might be worth exploring ways to avoid always binding $this for stuff like this case.

[iluuu1994]

I know it's needed for stuff like self:: and parent:: in dynamic context, but it might be worth exploring ways to avoid always binding $this for stuff like this case.

I think rather than self:: and parent::, it's ParentClass:: and GrandParentClass::, which don't indicate whether they are instance or static calls, purely syntactically.

Edit: Actually, you're of course also right, same applies to parent:: (or self:: for trait methods), if it calls a method other than the current one which isn't known to be static.

What we could probably do though is make closer static if they neither use $this nor have any static method call syntax (which again may actually be a hidden instance call).

[dktapps]

Yep. So my thought is that a closure which doesn't call any possibly-non-static functions in its hierarchy (and doesn't use $this) could be automatically considered static. That should be quite a common case, no?

[iluuu1994]

I looked at automatically marking closures as static again, when they don't use $this or make static calls. The main issue is that $staticClosure->bindTo($obj) currently fails and returns NULL. Similarly, $staticClosure->call($obj) will throw. What's worse is that this error would appear seemingly randomly, depending on whether you're using any of the features that prevents the function from becoming static (call_user_func(), and thus any dynamic call that may call call_user_func(), calling any static method, using varvar that may access $this, nested non-static closures, etc.).

We could just discard the object in this case, though there is still a smaller BC break of returning NULL for ReflectionFunction::getClosureThis(). I'll try this approach in the coming days.

[dktapps]

What about just allowing binding of $this to static closures, then?

It already seems to be fine to call a conventional static method using dynamic syntax, and adding a redundant $this wouldn't break anything. So it doesn't make much sense to me to restrict it.

https://3v4l.org/JjW0uW

[iluuu1994]

We shouldn't bind $this for static calls. We've gotten rid of similar hacks, we shouldn't reintroduce them.