> -----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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
