|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2021-09-07 17:11 UTC] nospam at briat dot org
Description: ------------ When debugging a sudden slow down (20 time slow) in https://www.drupal.org/project/advagg module for Drupal 7 which use this cssmin.php v2.4.8-4, I discover that its massive uses of preg_replace was the core of the problem. I notice that I have the problem with some versions of PHP: PHP 7.3.27-9+0~20210227.82+debian9~1.gbpa4a3d6 (cli) (built: Feb 27 2021 15:51:31) or php:7.4.12-cli-alpine but not with PHP 7.3.12 (cli) (built: Nov 22 2019 16:32:31) ( NTS ) or php:7.4.11-cli-alpine I made a small script that run different version of php with docker and the gap occur on php:7.4.12-cli-alpine or +. Since it not quite related to the PHP version, I could be related to the PCRE Library Version 10.35 or + or the #81243. Test script: --------------- # Create a huge css file with one selector of 15k char on the first line # following by some rules composer require tubalmartin/cssmin <?php require './vendor/autoload.php'; use tubalmartin\CssMin\Minifier as CSSmin; $my_cssmin = new CSSmin(true); $data = file_get_contents('test.css'); $time_start = microtime(true); $data = $my_cssmin->run($data, 4096); echo PHP_EOL . strlen($data) . ' char. in ' . ( microtime(true) - $time_start ) . 's.' . PHP_EOL; Expected result: ---------------- the two docker executions should have similar execution times Actual result: -------------- docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp php:7.4.11-cli-alpine php test.php 17091 char. in 0.0034229755401611s. docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp php:7.4.11-cli-alpine php -i |egrep "(PCRE|reg)" register_argc_argv => On => On Multibyte (japanese) regex support => enabled Multibyte regex (oniguruma) version => 6.9.5 mbstring.regex_retry_limit => 1000000 => 1000000 mbstring.regex_stack_limit => 100000 => 100000 PCRE (Perl Compatible Regular Expressions) Support => enabled PCRE Library Version => 10.34 2019-11-21 PCRE Unicode Version => 12.1.0 PCRE JIT Support => enabled PCRE JIT Target => x86 64bit (little endian + unaligned) Phar fully realized by Gregory Beaver and Marcus Boerger. docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp php:7.4.12-cli-alpine php test.php lorem: 17091char. in 0.20809006690979s. docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp php:7.4.12-cli-alpine php -i |egrep "(PCRE|reg)" register_argc_argv => On => On Multibyte (japanese) regex support => enabled Multibyte regex (oniguruma) version => 6.9.5 mbstring.regex_retry_limit => 1000000 => 1000000 mbstring.regex_stack_limit => 100000 => 100000 PCRE (Perl Compatible Regular Expressions) Support => enabled PCRE Library Version => 10.35 2020-05-09 PCRE Unicode Version => 13.0.0 PCRE JIT Support => enabled PCRE JIT Target => x86 64bit (little endian + unaligned) Phar fully realized by Gregory Beaver and Marcus Boerger. PatchesPull Requests
Pull requests:
HistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Oct 26 17:00:01 2025 UTC |
Simpler reproducer: <?php $data = file_get_contents("lorem.css.txt"); $time_start = hrtime(true); var_dump(preg_match('/[^{};\/\n]+\{\}/S', $data)); var_dump( strlen($data), (hrtime(true) - $time_start) / 100000 ); ?> Yields a performance regression by more than factor 100 for me. I'm not sure, though, whether the PCRE2 maintainers would fix this, since the regex appears to be suboptimal. Using a look behind assertion var_dump(preg_match('/(?<![{};\/\n]+)\{\}/S', $data)); instead, makes almost no performance difference.