Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain meetme.com designates 74.125.149.145 as permitted sender)
Sender: Will Fitch <wfitch@meetme.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C7EC928B-E9A9-461B-92B1-0680A274876E"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-Reply-To: <CAMUwpuT2x0-gfbob6+d4xmg8-QOxG20PW6xnUNgFspBSFUBTLw@mail.gmail.com>
Date: Fri, 25 Jan 2013 12:40:29 -0500
Cc: Zeev Suraski <zeev@zend.com>,
 Rasmus Lerdorf <rasmus@lerdorf.com>,
 Ralf Lang <lang@b1-systems.de>,
 internals@lists.php.net
Message-ID: <B7B10CED-95E0-4877-943E-E4D64243DA7E@php.net>
References: <slrnkg3ag2.g88.dsp@experimentalworks.net> <CAJW__o2gncnxnAGd7M7jZjxGADzt2D9xYQOyhp_797Lebx5JSA@mail.gmail.com> <CAL+t6cH6b290+T9=dLp_FFaFCAUiJumx9zvWQNiUr5KfKyunXQ@mail.gmail.com> <51023AB1.2010607@b1-systems.de> <51024016.4010005@lerdorf.com> <c2813d225363300a730e2d4009ae3ec1@mail.gmail.com> <6AA61A4F-ABF0-4FF2-A509-3FE70297B744@php.net> <CAMUwpuT2x0-gfbob6+d4xmg8-QOxG20PW6xnUNgFspBSFUBTLw@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: willfitch@php.net (Will Fitch)

--Apple-Mail=_C7EC928B-E9A9-461B-92B1-0680A274876E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jan 25, 2013, at 11:52 AM, Julien Pauli <jpauli@php.net> wrote:

> On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch <willfitch@php.net> wrote:
>=20
> On Jan 25, 2013, at 11:25 AM, Zeev Suraski <zeev@zend.com> wrote:
>=20
> >> Either by a number of people stepping up to help with the existing =
APC
> > code, or
> >> perhaps more realistically making it a priority in PHP 5.6 to =
streamline
> > the
> >> engine and the executor for opcode caching and either including a
> > heavily
> >> simplified version of APC or writing a new one.
> >>
> >> One thing I can guarantee is that if we add it to core in its =
current
> > condition it
> >> will delay 5.5 by 6+ months if not longer.
> >
> > There's another option.  We have the Optimizer+ component which is
> > current, a bit faster than APC, worked with PHP 5.4 from the get go =
and
> > already fully supports 5.5 - and now that it's been free for use for
> > several years, we'd actually be happy to opensource it and make it a =
part
> > of core.  An extra benefit would be that we'd commit to maintain it,
> > although of course, community contribution will be very welcome.
> > Here too, it's code with a very long history, some of which even =
predates
> > PHP 4.0.  But It Works(tm), and we could put some effort into =
cleaning it
> > up and beautifying it.
>=20
> I like the idea.  If this was implemented in core, and the need for =
APC opcode caching disappeared, would APC still be actively maintained =
for userland functions (e.g. apc_store, apc_*)?
>=20
> Well, the APC idea was anyway to merge an Opcode cache to Core, and =
only an Opcode cache (correct if I'm wrong).
> apc_store() etc... are userland shared memory function, and should be =
migrated into another extensions, on which we could then allocate devs =
to work on, new ideas, etc=85

No, you're right.  With Optimizer+ showing a slightly better performance =
than APC, being "privately" and publicly maintained, open-sourced, =
already compatible up to 5.5, I see it as a great candidate for core =
integration.  I'd still like to keep APC as a separate extension, but =
packaged with PHP, for data-only caching.

@Zeev, is anyone writing up an RFC for this?

>=20
> Julien.Pauli


--Apple-Mail=_C7EC928B-E9A9-461B-92B1-0680A274876E--