Bug #73265 [Opn]: Loading browscap.ini at startup causes high memory usage

From: Date: Sat, 17 Dec 2016 15:32:25 +0000
Subject: Bug #73265 [Opn]: Loading browscap.ini at startup causes high memory usage
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-206101@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73265&edit=1

 ID:                 73265
 Updated by:         nikic@php.net
 Reported by:        spam2 at rhsoft dot net
 Summary:            Loading browscap.ini at startup causes high memory
                     usage
 Status:             Open
 Type:               Bug
 Package:            Performance problem
 Operating System:   Linux
 PHP Version:        7.0.14
-Assigned To:        
+Assigned To:        nikic
 Block user comment: N
 Private report:     N

 New Comment:

Compiled patterns are cached across requests. The cache size is limited (IIRC 4k patterns).
get_browser() with the current implementation and the large browscap.ini file matches significantly
more than 4k patterns on each call, so you don't benefit from the caching (as patterns are
displaced before they can be used again).


Previous Comments:
------------------------------------------------------------------------
[2016-12-17 14:45:54] spam2 at rhsoft dot net

is the result of the prce-jit somewhere stored between requests?

i still try to understand what goes up behind the scenes

without the pcre-jit 3 preg_replace() and 2 preg_match() goes up from 1.22 / 0.54% runtime costs to
15% (higly optimized core-cms) and so the JIT makes a really perofrmance boost - but looking at the
source i have 5 different patterns and so within the request there is hardly a reuse and only reuse
within requests could explain a benefit

that would also explain the dramatical memory usage of browscap but on the other hand not the drop
of get_browser() within a loop instead make if faster after the first call

------------------------------------------------------------------------
[2016-12-16 19:01:57] nikic@php.net

PR up at https://github.com/php/php-src/pull/2242.
Quoting the performance numbers:

> * According to massif, the peak memory usage of PHP drops from 85MB to 23MB.
> * The startup time of PHP drops from 0.19s to 0.10s.
> * The time of running the get_browser_basic.phpt test with this ini drops from 19s to 0.23s.
> (!!!)

------------------------------------------------------------------------
[2016-12-16 18:31:33] nikic@php.net

It is a runtime option, see pcre.jit.

The PCRE JIT optimizes the case where a pattern is compiled once and used multiple times. Browscap
instead uses a huge amount of patterns only once. In this case the overhead of JIT compilation is
larger than the benefit during the matching of the pattern.

------------------------------------------------------------------------
[2016-12-16 17:29:31] spam2 at rhsoft dot net

indeed PHP 7.1 build with "--without-pcre-jit" is faster, while fast is relative given
that the test did only 10 calls - what is the purpose of the JIT then and can this not be a runtime
option for the cases where it brings a benefit?


<?php
 $loops = 10;
 for($count=1; $count<=$loops; $count++)
 {
  $x = get_browser('Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101
Firefox/50.0');
 }
?>

[harry@srv-rhsoft:/scripts/php5-versus-7]$ ./test.sh
PHP 5.6
real    0m5.922s
user    0m5.861s
sys     0m0.027s

PHP 7.0
real    0m14.894s
user    0m14.716s
sys     0m0.079s


PHP 7.1
real    0m3.335s
user    0m3.285s
sys     0m0.031s

------------------------------------------------------------------------
[2016-12-16 16:57:15] spam2 at rhsoft dot net

wait - the JIT makes things slower?
i had assumed the opposite

so you tell me the change below should be the exactly opposite and with 7.1 configure can disable it
while --without-pcre-jit don't exist for 7.0 and it's always enabled there?

* Thu Dec 8 2016 Reindl Harald <h.reindl@thelounge.net>
- update to PHP 7.0.14
- add 'with-pcre-jit' for upcoming 7.1 to configure

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=73265


--
Edit this bug report at https://bugs.php.net/bug.php?id=73265&edit=1


Thread (35 messages)

« previous php.bugs (#206101) next »