Three times faster. That is the number in the benchmark posts about PHP 8.4, where simple sprintf() calls with basic placeholders get turned into plain string operations at compile time. The function call disappears.
for ($i = 0; $i < 1000000; $i++) {
$s = sprintf('%s-%d', $prefix, $i);
}
I like this work. I do not like how people read it.
A microbenchmark measures one function in a loop, alone, with a warm cache and nothing else to do. Now profile a real request from the same application. In every backend I have profiled the picture has the same shape: most of the wall time is waiting. SQL queries, Redis round trips, an HTTP call to some partner API. The CPU spent inside PHP is a modest slice, and sprintf inside that slice is a rounding error. Three times faster rounding error is still a rounding error.
This gives a simple order for optimization work, from big to small. Architecture first: do not do the work at all, cache the page, precompute the answer. Then I/O: the N+1 query, the missing index, the API call in a loop. Then the hot CPU paths the profiler actually points at, usually serialization or hydration of thousands of objects. Micro wins come last, and mostly they come for free with the engine upgrade, which is exactly what 8.4 does for everyone at once.
That is the honest praise. Engine optimizations are wonderful because nobody has to change their code to get them. Take the free percent and say thank you. Just do not book it as your performance strategy.
Your p99 lives in the database. I know this, and I still opened the sprintf PR before the slow query log this morning.