Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heroku.com designates 74.125.82.52 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
In-Reply-To: <CAF+90c8V4bD5+Sq2t63A=PJiW78DFdwE42oLAj7HMiQemn0mHA@mail.gmail.com>
Date: Wed, 15 Mar 2017 10:37:53 +0100
Cc: PHP internals list <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E2D31F36-EDE7-453A-AD59-84FEA63E60D5@heroku.com>
References: <5BF394D3-919E-4140-AFF9-F46223AB49C4@heroku.com>
 <CAF+90c8V4bD5+Sq2t63A=PJiW78DFdwE42oLAj7HMiQemn0mHA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7
 with huge classes
From: dz@heroku.com (David Zuelke)

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
>> ....
>>=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.

Alright, thanks! I opened a bug for it: =
https://bugs.php.net/bug.php?id=3D74250