Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65392
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5107D429.60001@lerdorf.com>
References: <5d21b42656d49b4a71d9f808541bd745@mail.gmail.com>
	<252ADB1A-2660-4A45-B859-B92DA2C8B8D8@gmail.com>
	<CAAyV7nEW_tHNObKcH3knin0-GPXakUiv1KoHYzjHiOJ1EB=wRg@mail.gmail.com>
	<5107CEEB.9080003@zerocue.com>
	<5107D429.60001@lerdorf.com>
Date: Tue, 29 Jan 2013 15:13:06 +0100
Message-ID: <CAF+90c_QrxD+OUT5s7s7kZp+4hmkNF-wy1K5_6a5Psa8CZzzqw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Clint Priest <cpriest@zerocue.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0401678f1eae5204d46dfe8d
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d0401678f1eae5204d46dfe8d
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 29, 2013 at 2:52 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 01/29/2013 05:30 AM, Clint Priest wrote:
>
> > 2) Isn't APC the standard?  Is it in such bad shape it is not even being
> > considered any longer?
>
> As it currently stands from a developer participation standpoint it is
> not viable. I outlined the issues in a previous post.
>
> You also have to take into account that most sites can't actually move
> to the next release of PHP until APC is stable with it. So effectively
> the PHP 5.4 release didn't happen until APC 3.1.13 in September 2012
> which was a full 6 months after PHP 5.4.0. I don't foresee this getting
> any better for PHP 5.5.
>
> In order for PHP releases to actually mean something this is a problem
> we have to fix. I honestly don't care which opcode cache implementation
> we base a core version on, what I care about is developer buy-in. Dmitry
> and Stas being familiar with the code already outnumbers the number of
> active core devs working on APC today.
>
> I understand some of the skepticism and hurt feelings around this from a
> few old-timers, but let's move on and see if we can finally push out a
> release with solid opcode caching right at the release date. From my
> perspective anything up to a 6-month delay would beat the current
> situation.
>

I'm not sure I fully understand this. The RFC claims that Optimizer+ is
already *now* fully compatible with PHP 5.5. And that it was also
compatible when PHP 5.4 was released. So they lack of a working and free
opcode cache clearly wasn't the issue. My guess is rather that the lack of
APC support (as in specifically APC and not just some opcode cache) was an
issue. Either because people didn't know about alternatives (APC after all
is the go-to opcode cache), didn't want to try them or had software tightly
integrated with APC (and in particular its user cache).

Just to be clear: I fully agree that PHP needs a working opcode cache when
PHP 5.5 ships, otherwise adoption will be like 5.4. But I'm not sure what
exactly changes between Optimizer+ being in core (enable via configure) and
Optimizer+ being in PECL (enable via install).

The main point I always saw behind including APC in core is that it would
require core developers to maintain it and to update it when doing ZE
changes, on their own. This doesn't seem to be a motivation for Optimizer+.
 Apart from that I see rather little difference between core/pecl. Opcode
caching is the kind of thing where the "if it's in pecl nobody will use it"
logic does not apply, as people using opcode caches run their own servers.
I do get that opcode caching
is commonly needed, so it would be nice to have it in core (easier
installation?), but I don't see why we should put off the release for one,
two, or more months, for that small convenience.

Thanks,
Nikita

--f46d0401678f1eae5204d46dfe8d--