We have/require symfony/polyfill-php80 and symfony/polyfill-php81...

Is there much (any?) performance loss to swapping to using it now, for those who aren't on PHP 8.0+ already?

In T338103#8900961, @Reedy wrote:

We have/require symfony/polyfill-php80 and symfony/polyfill-php81...

Is there much (any?) performance loss to swapping to using it now, for those who aren't on PHP 8.0+ already?

Not just "much", but a massive lot unfortunately:

<?php

$num = 100000000;
$str = 'abcdefghijklmno';

$s = hrtime(true);
for ( $i = 0; $i < $num; $i++ ) {
    $res1 = ord( $str ) === 95;
}
$time = (hrtime( true ) - $s)/10**6;
echo "ORD: $time\n";

$s = hrtime(true);
for ( $i = 0; $i < $num; $i++ ) {
    $res3 = str_starts_with( $str, '_' );
}
$time = (hrtime( true ) - $s)/10**6;
echo "START: $time\n";

class SymfonyPhp80 {
	public static function str_starts_with2(string $haystack, string $needle): bool
    {
        return 0 === strncmp($haystack, $needle, \strlen($needle));
	}
}

function str_starts_with2(?string $haystack, ?string $needle): bool { return SymfonyPhp80::str_starts_with2($haystack ?? '', $needle ?? ''); }

$s = hrtime(true);
for ( $i = 0; $i < $num; $i++ ) {
    $res3 = str_starts_with2( $str, '_' );
}
$time = (hrtime( true ) - $s)/10**6;
echo "START SYM: $time\n";

$ php8.1 test.php 
ORD: 1573.309082
START: 1598.216216
START SYM: 6385.82479

(Also note that in this test run ord() is faster than str_starts_with())

Using the polyfill involves a userland function call, two null coalesces, a userland method call, and an underlying implementation that uses strncmp, strlen, and a comparison. This wouldn't matter in ordinary code, but since this code is (or at least was) extremely hot, any slowdown matters, particularly a 4x one.

I wonder if this method really is that hot—in the api.php-specific wall time flamegraph for May 8th, I get no hits at all for the method name, and ApiResult shows up as ~0.1%, which is so little that I have trouble finding it in the flamegraph. In the CPU time graph, ApiResult::applyTransformations shows up as responsible for ~0.4% of CPU time, but isMetadataKey is not visible there either.

I368cd3b526edeb247a6ebda7420897a51357407d appears to have been based on an XHGui profile, which tends to overstate the impact of small functions called relatively often.