Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98643
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heroku.com designates 209.85.128.171 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
In-Reply-To: <B9D93120-A9DD-43E5-8B44-D9CC4DDAD0EC@heroku.com>
Date: Mon, 27 Mar 2017 22:58:40 +0200
Cc: ab@php.net,
 Ferenc Kovacs <tyrael@php.net>,
 Nikita Popov <nikita.ppv@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <FCE94089-412F-49E4-AF6F-04529518CAD9@heroku.com>
References: <5BF394D3-919E-4140-AFF9-F46223AB49C4@heroku.com>
 <CAF+90c8V4bD5+Sq2t63A=PJiW78DFdwE42oLAj7HMiQemn0mHA@mail.gmail.com>
 <B9D93120-A9DD-43E5-8B44-D9CC4DDAD0EC@heroku.com>
To: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7
 with huge classes
From: dz@heroku.com (David Zuelke)

Just another poke to surface it, in case this should be merged into the =
7.0 branch as well :)

https://bugs.php.net/bug.php?id=3D74250


> On 19. Mar 2017, at 23:39, David Zuelke <dz@heroku.com> wrote:
>=20
> Thanks for the fixes, Nikita!
>=20
> Will they be merged to the PHP-7.0 branch as well?
>=20
>=20
>> On 14 Mar 2017, at 16:39, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>=20
>> On Tue, Mar 14, 2017 at 11:29 AM, David Zuelke <dz@heroku.com> wrote:
>> Hi all,
>>=20
>> There appears to be a performance regression in the CFG and DFA based =
optimization passes of OPcache in PHP 5.6+ when loading huge classes =
(such as those generated by Symfony's routing component) for the first =
time.
>>=20
>> The issue does not occur on PHP 5.5. Tests below are with 5.6.30, =
7.0.16 and 7.1.2 and default INI settings; I replicated the issue on =
both macOS and Linux.
>>=20
>> Test file here (it's from an actual application, slightly anonymized, =
not a synthetic example): =
https://gist.github.com/dzuelke/fe867f55f09e0bf79ecefcc815b7fe92
>>=20
>> Without OPcache, everything is fine in all versions:
>>=20
>> $ time -p php -dopcache.enable_cli=3D0 hugeclass.php
>> real 0.10
>> user 0.09
>> sys 0.00
>>=20
>> With OPcache on, things are suddenly much, much slower:
>>=20
>> 5.6:
>>=20
>> $ time -p php -dopcache.enable_cli=3D1 hugeclass.php
>> real 3.23
>> user 3.21
>> sys 0.02
>>=20
>> 7.0:
>>=20
>> $ time -p php -dopcache.enable_cli=3D1 hugeclass.php
>> real 1.76
>> user 1.73
>> sys 0.02
>>=20
>> 7.1:
>>=20
>> $ time -p php -dopcache.enable_cli=3D1 hugeclass.php
>> real 4.01
>> user 3.98
>> sys 0.02
>>=20
>> For comparison, 5.5 is as speedy as you'd expect it to be:
>>=20
>> $ time -p php -dopcache.enable_cli=3D1 hugeclass.php
>> real 0.14
>> user 0.11
>> sys 0.02
>>=20
>> If we switch off optimization passes 5 (CFG based) and 6 (DFA based, =
only in 7.1), everything is great again in all versions:
>>=20
>> $ time -p php -dopcache.enable_cli=3D1 =
-dopcache.optimization_level=3D0x7FFFFFCF hugeclass.php
>> real 0.13
>> user 0.10
>> sys 0.02
>>=20
>> For 5.6 and 7.0, pass 6 is not a thing, but in 7.1, we can inspect =
passes 5 and 6 separately.
>>=20
>> Pass 5 (CFG based) already makes for a drastic performance hit in =
7.1:
>>=20
>> $ time -p php -dopcache.enable_cli=3D1 =
-dopcache.optimization_level=3D0x7FFFFFDF hugeclass.php
>> real 0.88
>> user 0.86
>> sys 0.01
>>=20
>> But pass 6 (DFA based) is the one that causes the biggest slowdown in =
7.1:
>>=20
>> $ time -p php -dopcache.enable_cli=3D1 =
-dopcache.optimization_level=3D0x7FFFFFEF hugeclass.php
>> real 3.29
>> user 3.24
>> sys 0.04
>>=20
>> In all versions, subsequent loads from the cache (such as when =
running FPM or the built-in web server) are fast.
>>=20
>> Is this slowness with a cold cache expected/accepted, or does that =
qualify as a bug?
>>=20
>> Yes, this is a bug. Optimization should never be this slow.
>>=20
>> =46rom a quick perf run, the problem in the DFA pass is that TI is =
quadratic in the number of calls (as call lookup is implemented as a =
linear scan). This can be fixed with a more efficient map lookup.
>> The problem in the CFG pass is that a large buffer is zeroed =
repeatedly.
>>=20
>> Nikita
>=20