Just an idea: it would interesting to have the optimisation running concurrently, to update the opcode cache with an optimised version, taking all the time it is needed for strong optimisations. If the optimisation is not ready for the first request it will be later when the optimisation is complete. The first hit would use the non optimised code, an optimiser would run to produce optimised opcode and eventually update APC cache. Starting with the second hit (or later if the optimisation takes time) the request would hit the faster cached opcode.
Devis On 4 December 2011 19:55, Tom Boutell <t...@punkave.com> wrote: > I see your point about optimization being time consuming and the > penalty being greater if you're not using a bytecode cache. But that's > a reason to make it optional, not a reason to couple it with a > specific bytecode cache so it can't be used with others. > > As for optimization not accomplishing all that much in PHP in general, > that I can't really argue with if it's true (: > > On Sun, Dec 4, 2011 at 12:10 PM, Graham Kelly <sgkel...@gmail.com> wrote: > > While it might seem like a good idea to put something like this into > > APC it really just creates more problems than it is worth. I belive it > > was removed for that very reason; because it was making it difficult > > to distinguish opcode cache errors from optimizer errors. > > > > There was an attempt to move this out of APC and into a pecl/optimizer > > extension but that never panned out. Additionally, the optimizations > > never yielded anything too substantial.The problem is that while you > > might be able to optimize away several opcodes you are still left with > > the general overhead incurred from running PHP which prevents you from > > getting too much further. Some of the optimizations have been moved > > into PHP 5.3 (constant folding) and PHP 5.4 but many of them still > > have not been (dead code elimination, various jump optimizations etc > > etc). > > > > The assumption that it would be better to move an optimization pass > > into PHP core so that all programs, even those not using an opcode > > cache, could benefit from them isnt holy accurate. Optimization takes > > time. A prime example of this is the fact that optimization comprises > > the majority of the time spent by most C compilers. Without an opcode > > cache it is very possible that the amount of time spent to optimize a > > section of code could be longer than the amount of time/memory saved > > by it. > > > > Ultimately, advances will continue to be made in terms of PHP > > performance. But, those will probably not happen in opcode caches and > > might not happen in optimizer specific extensions. > > > > On Sat, Dec 3, 2011 at 1:46 PM, Rasmus Lerdorf <ras...@lerdorf.com> > wrote: > >> On 12/03/2011 10:28 AM, Dmitri Snytkine wrote: > >>> APC is great, APC definetely speeds up the php a lot but I just > remember that there used to be also optimization options. > >>> I remember the days where eAccelerator and php accelerator and mmcache > were popular. They all had code optimization option to speed up compiled > scripts. > >> > >> Many of those optimizations have been either rolled into the standard > >> compiler or made irrelevant by changes to the opcodes themselves. > >> > >> -Rasmus > >> > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
