You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Performance of preg_match varies depending on how subject string is initialized #24380
Execution time A: […]
Execution time A: 0.052051 sec.
Execution time B: 0.054563 sec.
Execution time C: 0.052694 sec.
Execution time D: 0.030555 sec.
Execution time A: 0.052350 sec.
Execution time B: 0.052309 sec.
Execution time C: 0.052223 sec.
Execution time D: 0.030175 sec.
But I expected this output instead:
All execution times should nearly be identical.
$textD is somehow fastest for PHP 8.4 and 8.5
$textB and $textD are fastest for PHP 8.2 and PHP 8.3
This is expected. With /u, preg_match() checks that the subject is valid UTF-8, then marks the string so later calls skip the check, but it can't mark interned strings (php_pcre.c). Only D is built at runtime; A and C are compile-time literals, and so is B since 8.4 (#14546).
Indeed, depending on how something is compiled or how something is initialized, you can get different performance characteristics.
Passing fixed compile-time (and thus interned) strings to preg_match to check its performance isn't realistic anyway, microbenchmarks can be deceiving.
Some common use cases have fast paths, so you can always find cases where functions behave differently because of what's commonly found in real-world code.
Closing as not a bug.
Activity
lazerg commentedon Oct 17, 2026
This is expected. With
/u, preg_match() checks that the subject is valid UTF-8, then marks the string so later calls skip the check, but it can't mark interned strings (php_pcre.c). Only D is built at runtime; A and C are compile-time literals, and so is B since 8.4 (#14546).ndossche commentedon Oct 17, 2026
Indeed, depending on how something is compiled or how something is initialized, you can get different performance characteristics.
Passing fixed compile-time (and thus interned) strings to preg_match to check its performance isn't realistic anyway, microbenchmarks can be deceiving.
Some common use cases have fast paths, so you can always find cases where functions behave differently because of what's commonly found in real-world code.
Closing as not a bug.