Will apc.optimization ever be put back to APC?

13 years ago by Dmitri Snytkine — view source

unread

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"

13 years ago by Tom Boutell — view source

unread

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

13 years ago by Ferenc Kovacs — view source

unread

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

13 years ago by Dmitri Snytkine — view source

unread

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,

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

13 years ago by Rasmus Lerdorf — view source

unread

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

13 years ago by Graham Kelly — view source

unread

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

13 years ago by Tom Boutell — view source

unread

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.

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

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

13 years ago by devis@lucato.it — view source

unread

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 (:

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 rasmus@lerdorf.com
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

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com