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

Edit report at https://bugs.php.net/bug.php?id=73265&edit=1 ID: 73265 User updated by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: Loading browscap.ini at startup causes high memory usage Status: Assigned Type: Bug Package: Performance problem Operating System: Linux PHP Version: 7.0.14 Assigned To: nikic Block user comment: N Private report: N New Comment: > For the server SAPIs it makes sense to load the browscap.ini at startup honestly i doubt - in case a server has configured it but no application is using get_browser() you have the full overhead for no good reason doing the same as happnes at startup but only on-demand when it#s first used would also free the servers where it is unused from the overhead and for the first get_browser() call it don't make a difference if that overhead happened at startup or on-demand Previous Comments: ------------------------------------------------------------------------ [2016-12-17 20:12:51] nikic@php.net For the server SAPIs it makes sense to load the browscap.ini at startup, so it's loaded only once. E.g. if you're using fpm this means it's loaded once and then will be shared (via cow) across all forked worker processes. However, I agree that for the cli SAPI it doesn't make sense to load the browscap.ini at startup -- we don't gain anything by that, but increase memory usage and startup time even if get_browser() is never used. ------------------------------------------------------------------------ [2016-12-17 17:43:59] spam2 at rhsoft dot net BTW: shouldn't the whole 'browsecap.ini' parsing not only happen when 'get_browser' is the first time called - that would save the whole overhead on a lot of systems and especially for CLI scripts which don't make use of it at all ------------------------------------------------------------------------ [2016-12-17 15:34:40] spam2 at rhsoft dot net thanks foor the feedback and especially for the patch - the numbers are damned impressive! ------------------------------------------------------------------------ [2016-12-17 15:32:25] nikic@php.net 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). ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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