Will apc.optimization ever be put back to APC? View as Markdown

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
dsnytkine@ultralogistics.com 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

--

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

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.

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