Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67059
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <51673FD1.2010704@garfieldtech.com>
Date: Thu, 11 Apr 2013 17:57:21 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: internals@lists.php.net
References: <CA+9eiLsjK0wTT4L0UN9uJdSJgO8se3YDebZwSHycrqAJswJufQ@mail.gmail.com> <CAL0xaBECR92ur0SDVZzYyh23+d-UnBE+DUjqkEAJZ=1EtUyNTQ@mail.gmail.com> <CAA9esyQg1trZcmr-7oR05eTGr87kDm4nHLXsvHnc983Ei=tNmg@mail.gmail.com> <CA+9eiLu8-jtAo1KX3yFEj658zbnxx4p+i=b3J6vvwTjZM7wypQ@mail.gmail.com>
In-Reply-To: <CA+9eiLu8-jtAo1KX3yFEj658zbnxx4p+i=b3J6vvwTjZM7wypQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
From: larry@garfieldtech.com (Larry Garfield)

Speaking as a userspace developer and site admin, I'd be fine with 
trading a more expensive compilation for a runtime improvement.  Even a 
100% increase in compilation time would pay for itself over only a dozen 
or so requests (assuming the runtime improvements are non-trivial, too).

Naturally some optimizations are harder to do than others given PHP's 
architecture, but trading more expensive compile for cheaper runtime, 
even if not a 1:1 trade, would be a win IMO.

--Larry Garfield

On 4/10/13 9:16 AM, Dmitry Stogov wrote:
> For now, the optimizations we do are quite chip.
> They may increase the compilation time on first request by 2, but on
> following requests we will get it back.
> Once we come to really expensive optimizations we will do it "offline" (in
> context of a separate process).
>
> Thanks. Dmitry.
>
>
> On Wed, Apr 10, 2013 at 5:16 PM, Florin Patan <florinpatan@gmail.com> wrote:
>
>>> On Wed, Apr 10, 2013 at 4:07 PM, Arvids Godjuks <arvids.godjuks@gmail.com>
>> wrote:
>>> 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$
>>
>> Hello,
>>
>>
>> If applying optimizations in multiple passes would be a problem for
>> speed, especially on the first request, then maybe a way to solve this
>> would be to have a configurable variable like: opcache.passes which is
>> between 1 and 10 (lets say) and then have the engine do something like
>> this:
>> - load the file, compile it and apply a first round of 'quick'
>> optimizations for the first time and mark it as passed once;
>> - next request, load the compiled version, apply another round of
>> optimization then mark it as a second pass
>> - repeat the above step until the optimization passes in the said file
>> = opcache.passes value
>>
>> This way only the initial requests will be affected by this but in a
>> way that the hit on those requests is smaller that applying all the
>> steps at once.
>> I'm really not sure if it's that easy to implement but 'on paper' this
>> could be the way to solve it imho.
>>
>> What do you think, does it make sense?
>>
>>
>>
>> Best regards
>> ----
>> Florin Patan
>> https://github.com/dlsniper
>> http://www.linkedin.com/in/florinpatan
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>