# Will apc.optimization ever be put back to APC? - Thread: https://externals.io/message/56733 - Original archive: https://news-web.php.net/php.internals/56733 - Started by Dmitri Snytkine on 2011-12-03T16:04:16+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #56733 — Dmitri Snytkine — 2011-12-03T16:04:16+00:00 URL: https://externals.io/message/56733#56733 The option apc.optimization has been removed in apc 3.0.13 I wonder if there are any plans to put the code optimization option back into APC, so the APC will be not only the cache of php files but also act as an accelerator? Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytkine@ultralogistics.com Web: www.ultralogistics.com "A Top 100 Logistics I.T. Provider in 2011" --- ## #56735 — Tom Boutell — 2011-12-03T17:24:23+00:00 URL: https://externals.io/message/56733#56735 · In reply to: #56733 This feature was described as "experimental" in the documentation. Maybe the "experiment" didn't work out - or it worked out fine and equivalent optimizations are part of the normal compliation of PHP code now? I would hope the latter - it doesn't seem like a bytecode cache should have to do optimizations; that would be the compiler's job and would benefit everyone regardless of which cache they use. Sensible factoring would not blur the roles of those two components. But I haven't delved into the source to find out what this option really did (: On Sat, Dec 3, 2011 at 11:04 AM, Dmitri Snytkine wrote: > The option apc.optimization has been removed in apc 3.0.13 > I wonder if there are any plans to put the code optimization option back > into APC, so the APC will be not only the cache of php files but also act as > an accelerator? > > > > Dmitri Snytkine > Web Developer > Ultra Logistics, Inc. > Phone: (888) 220-4640 x 2097 > Fax: (888) 795-6642 > E-Mail: dsnytkine@ultralogistics.com > Web: www.ultralogistics.com > > "A Top 100 Logistics I.T. Provider in 2011" > > > > > -- > > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #56736 — Ferenc Kovacs — 2011-12-03T17:39:13+00:00 URL: https://externals.io/message/56733#56736 · In reply to: #56735 hi, see http://svn.php.net/viewvc?view=revision&revision=224572 and http://svn.php.net/viewvc/pecl/apc/trunk/TECHNOTES.txt?r1=224572&r2=224571&pathrev=224572 especially it seems that it doesn't work out, and it was removed. So I'm pretty sure, that we won't see that option in the future. If the apc devs would come up with another optimization, using the same ini option to controll it would be really confusing, so even in that case, some other name would be chosen. btw. Dmitri I don't really get the "so the APC will be not only the cache of php files but also act as an accelerator?" part, what do you miss from apc? I don't see anything in that change which would back up your comment. just my 2 cents ofc, maybe others can better answer this. > This feature was described as "experimental" in the documentation. > Maybe the "experiment" didn't work out - or it worked out fine and > equivalent optimizations are part of the normal compliation of PHP > code now? > > I would hope the latter - it doesn't seem like a bytecode cache should > have to do optimizations; that would be the compiler's job and would > benefit everyone regardless of which cache they use. Sensible > factoring would not blur the roles of those two components. But I > haven't delved into the source to find out what this option really did > (: > > On Sat, Dec 3, 2011 at 11:04 AM, Dmitri Snytkine > wrote: > > […] > act as > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > > > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56737 — Dmitri Snytkine — 2011-12-03T18:28:57+00:00 URL: https://externals.io/message/56733#56737 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. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytkine@ultralogistics.com Web: www.ultralogistics.com "A Top 100 Logistics I.T. Provider in 2011" -----Original Message----- From: Ferenc Kovacs [mailto:tyra3l@gmail.com] Sent: Saturday, December 03, 2011 12:39 PM To: Tom Boutell Cc: PHP Internals Subject: Re: [PHP-DEV] Will apc.optimization ever be put back to APC? hi, see http://svn.php.net/viewvc?view=revision&revision=224572 and http://svn.php.net/viewvc/pecl/apc/trunk/TECHNOTES.txt?r1=224572&r2=224571&pathrev=224572 especially it seems that it doesn't work out, and it was removed. So I'm pretty sure, that we won't see that option in the future. If the apc devs would come up with another optimization, using the same ini option to controll it would be really confusing, so even in that case, some other name would be chosen. btw. Dmitri I don't really get the "so the APC will be not only the cache of php files but also act as an accelerator?" part, what do you miss from apc? I don't see anything in that change which would back up your comment. just my 2 cents ofc, maybe others can better answer this. > This feature was described as "experimental" in the documentation. > Maybe the "experiment" didn't work out - or it worked out fine and > equivalent optimizations are part of the normal compliation of PHP > code now? > > I would hope the latter - it doesn't seem like a bytecode cache should > have to do optimizations; that would be the compiler's job and would > benefit everyone regardless of which cache they use. Sensible > factoring would not blur the roles of those two components. But I > haven't delved into the source to find out what this option really did > (: > > On Sat, Dec 3, 2011 at 11:04 AM, Dmitri Snytkine > wrote: > > […] > act as > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > > > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56738 — Rasmus Lerdorf — 2011-12-03T18:46:36+00:00 URL: https://externals.io/message/56733#56738 · In reply to: #56737 > 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 --- ## #56769 — Graham Kelly — 2011-12-04T17:10:25+00:00 URL: https://externals.io/message/56733#56769 · In reply to: #56738 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. > > > […] > > Many of those optimizations have been either rolled into the standard > compiler or made irrelevant by changes to the opcodes themselves. > > -Rasmus --- ## #56772 — Tom Boutell — 2011-12-04T19:55:29+00:00 URL: https://externals.io/message/56733#56772 · In reply to: #56769 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 (: > 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. > > > > […] -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #56773 — devis@lucato.it — 2011-12-04T20:45:39+00:00 URL: https://externals.io/message/56733#56773 · In reply to: #56772 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 > 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 (: > > > > […] > wrote: > > […] > remember that there used to be also optimization options. > > […] > were popular. They all had code optimization option to speed up compiled > scripts. > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com