Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67030
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAA9esyQg1trZcmr-7oR05eTGr87kDm4nHLXsvHnc983Ei=tNmg@mail.gmail.com>
References: <CA+9eiLsjK0wTT4L0UN9uJdSJgO8se3YDebZwSHycrqAJswJufQ@mail.gmail.com>
 <CAL0xaBECR92ur0SDVZzYyh23+d-UnBE+DUjqkEAJZ=1EtUyNTQ@mail.gmail.com> <CAA9esyQg1trZcmr-7oR05eTGr87kDm4nHLXsvHnc983Ei=tNmg@mail.gmail.com>
Date: Wed, 10 Apr 2013 16:26:55 +0300
Message-ID: <CAL0xaBF=CU6NCQch2Mf7PjekH1jhWWj0uM73Z9xhDRo_=b0sYA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043bd93cdc132604da01a02b
Subject: Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--f46d043bd93cdc132604da01a02b
Content-Type: text/plain; charset=UTF-8

2013/4/10 Florin Patan <florinpatan@gmail.com>

> >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
>

It could be a way out for heavy optimizations. Question is - will there be
any? :)

--f46d043bd93cdc132604da01a02b--