2013/4/10 Florin Patan <florinpa...@gmail.com>
> >On Wed, Apr 10, 2013 at 4:07 PM, Arvids Godjuks <arvids.godj...@gmail.com>
> wrote:
> > 2013/4/10 Dmitry Stogov <dmi...@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? :)
