Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67025
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLsjK0wTT4L0UN9uJdSJgO8se3YDebZwSHycrqAJswJufQ@mail.gmail.com>
References: <CA+9eiLsjK0wTT4L0UN9uJdSJgO8se3YDebZwSHycrqAJswJufQ@mail.gmail.com>
Date: Wed, 10 Apr 2013 16:07:31 +0300
Message-ID: <CAL0xaBECR92ur0SDVZzYyh23+d-UnBE+DUjqkEAJZ=1EtUyNTQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0141a9a48c10f304da015b2e
Subject: Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--089e0141a9a48c10f304da015b2e
Content-Type: text/plain; charset=UTF-8

2013/4/10 Dmitry Stogov <dmitry@zend.com>

> Hi,
>
> Recently, I've found that OPcache optimizer misses a lot of abilities,
> because it handles only one op_array at once. So it definitely can't
> perform any inter-function optimizations (e.g. inlining).
>
> Actually, it was not very difficult to switch to "script at once" approach.
> The attached patch demonstrates it and adds per script constants
> substitution explained in the following script
>
> <?php
> define("FOO", 1);
> function foo() {
>     echo FOO . "\n"; // optimizer will replace it with: echo "1\n";
> }
> ?>
>
> Of course, I ran the PHP test suite and it passed all the same tests.
> Personally, I think it's safe to include this patch into 5.5 and make a
> green light to some other advanced optimizations in 5.5. (e.g. conversion
> INIT_FCALL_BY_NAME into DO_FCALL).
>
> Any thoughts?
>
> Thanks. Dmitry.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Hi!

Many obvious optimizations are not used due to the fact, that script
translation into opcode state has to be fast. The nature of PHP dictated
that and this was re-iterated countless times on this mailing list by the
core developers.

To do advanced stuff, you have to create some sort of pre-compile or
storing that compiled code reliably on disk so that if memory cache is
dropped or restart is done, there is no significant preformance hit while
all the code compiles into optimized opcode again.

I would also imagine that good part of the optimizations would require
multiple files to be processed and optimized, but due to dynamic nature of
the PHP opcode compilation is done on per-file basis, so do the
optimizations.

It's very commendable that you want to push optimizations and stuff, but
there are some fundamental stuff that needs to be cared of to do some
really good stuff.

My 0.02$

--089e0141a9a48c10f304da015b2e--