2013/4/10 Zeev Suraski <z...@zend.com> > > -----Original Message----- > > From: Arvids Godjuks [mailto:arvids.godj...@gmail.com] > > Sent: Wednesday, April 10, 2013 4:08 PM > > To: PHP Internals > > Subject: Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5? > > > > 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. > > I think it very much depends on the nature of the optimizations. For the > vast majority of optimizations we can apply to PHP's execution > architecture, > I actually don't think that we need to go back to the fundamentals and > consider things like storing pre-compiled scripts on disk. The compiler, > even with optimization passes still takes split seconds to execute, which > means a 'cold boot' (e.g. when doing a restart) won't be a noticeably > painful process. As long as you end up reusing the results of that process > a lot more frequently than you have to recreate them - you're fine. > > Note that our experience was that reading binary serialized data from disk > isn't significantly faster than invoking the compiler in the first place - > you still have to read the data from disk, you still have to analyze it and > backpatch addresses, etc.; I know that some people here are revisiting > that > assertion - which is absolutely fine - but the assumption that saving > precompiled files on disk eliminates compilation overhead is wrong. If > anything it gives a marginal benefit... > > From my POV I think we're fine with any optimization that does not break > the > single-file barrier (in other words, no cross-file optimizations). The one > Dmitry suggested falls in that category, so I think it's fine, and it's > mostly a question of whether we want it in 5.5 or only in 5.6. > > Zeev >
Yep, I have to agree here. It all depends on the optimizations in question, the time it takes to preform them. Regarding the storage if compiled opcode on disk - my thought was to read from disk only if there are heavy enought optimizations present and be a one-time thing to populate the RAM cache. Also it is right now that invoking the compiler is not really slower than reading from disk, but in the future, when there are numerous optimization passes and stuff - it can become significant. Anyway - this is just my thoughts on the subject. People are also asking for the ability to deploy already compiled scripts (comercial software, faster deployment, etc), this maybe a part of a bigger functionality for the future.
