PHP CLI performance question: 8.1 vs 8.4

[fcharrier]

Description

Hello

I have heard about performance issues when running PHP into containers. I wanted to check with a simple performance test. I use this code (from https://stackoverflow.com/questions/73129021/host-php-vs-docker-php-5-times-slower)

<?php
$startTime = time();
$runSeconds = 5;
$rounds = 5;
$count = 0;
for ($i=0; $i<$rounds; $i++) {
    while ((time()-$startTime) <= $runSeconds) {
        serialize(['bar'=>'foo']);
        $count ++;
    }
    $round = $i+1;
    $startTime += $runSeconds;
    $count = number_format($count);
    echo "Round {$round}: {$count} /per {$runSeconds} second\n";
    $count = 0;
}

With this native version on my Ubuntu laptop I get this result:

PHP 8.1.32 (cli) (built: Mar 13 2025 18:27:13) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.32, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.32, Copyright (c), by Zend Technologies

Round 1: 67,536,708 /per 5 second
Round 2: 64,172,310 /per 5 second
Round 3: 66,127,986 /per 5 second
Round 4: 66,720,826 /per 5 second
Round 5: 66,609,499 /per 5 second

When running the same code into docker images, I get different results... But finally I can see it doesn't come from docker, but from PHP version. If I switch to 8.4, I get less performance:

PHP 8.4.10 (cli) (built: Jul  3 2025 12:41:53) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.10, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.10, Copyright (c), by Zend Technologies

Round 1: 45,043,192 /per 5 second
Round 2: 51,002,689 /per 5 second
Round 3: 51,224,938 /per 5 second
Round 4: 51,226,778 /per 5 second
Round 5: 51,235,970 /per 5 second

Is it something already known?

I read some papers about PHP performance, and results are not the same: 8.4 version should be equals or better than the 8.1 one.

Thanks

PHP Version

PHP 8.4.10 (cli) (built: Jul  3 2025 12:41:53) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.10, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.10, Copyright (c), by Zend Technologies

Operating System

Ubuntu 22.04.5 LTS

[nielsdos]

In general, newer PHP versions make improvements in performance in several areas. It's of course always possible that something slips through the cracks, especially while microbenchmarking.

Anyway, this is caused by 4df3dd7
I haven't dug into this yet to know whether this is a typical memory/time trade-off or if there's something more complex here.

[nielsdos]

Ah I see. That patch made sure to trim the created strings by using smart_str_trim_to_size. That reduces the memory usage but may cause a new allocation.
Sometimes a reallocation is not necessary, e.g. if we end up in the same bucket of a non-huge allocation then the extra allocation+copy was unnecessary. The same holds for functions like zend_string_truncate...
cc @arnaud-lb

[nielsdos]

Actually, since it calls perealloc this should already try to avoid the new allocation whenever possible...
I'm not sure what we can improve here.

[nielsdos]

Arnaud actually did some benchmarks: #8902 (comment)
The negative performance impact of the memory optimization decreases as the size of the string goes up. Your code results in a very small string, and the microbenchmark itself may also not be realistic regarding a real application.
So it looks like a typical memory-time trade-off.
I'll leave the final decision for Arnaud though.