Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56769
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EDA6E8C.6040105@lerdorf.com>
References: <012201ccb1d5$356a6fa0$a03f4ee0$@alliantinternet.com>
 <CAORXhGKrcJWZ-bAP1xBXa45ahdpzkoc1ikhObsfeVa2QJphoKw@mail.gmail.com>
 <CAH-PCH5Rytui7Jwrp-qouDyk-0=TrzbnqSJchzWoTSpPNXrjGg@alliantinternet.com>
 <012601ccb1e9$6b7aad80$42700880$@alliantinternet.com> <4EDA6E8C.6040105@lerdorf.com>
Date: Sun, 4 Dec 2011 12:10:25 -0500
Message-ID: <CAN17x3V99BOgRkg2epkeaGNVxHAw2uDCSOd=hPDZDgs4wiY0+w@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Dmitri Snytkine <dsnytkine@ultralogistics.com>, Ferenc Kovacs <tyra3l@gmail.com>, 
	Tom Boutell <tom@punkave.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Will apc.optimization ever be put back to APC?
From: sgkelly4@gmail.com (Graham Kelly)

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:
> 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
>