Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65172
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain meetme.com designates 74.125.149.238 as permitted sender)
Sender: Will Fitch <wfitch@meetme.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-Reply-To: <c2813d225363300a730e2d4009ae3ec1@mail.gmail.com>
Date: Fri, 25 Jan 2013 11:47:47 -0500
Cc: Ralf Lang <lang@b1-systems.de>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <6AA61A4F-ABF0-4FF2-A509-3FE70297B744@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>
To: Zeev Suraski <zeev@zend.com>,
 Rasmus Lerdorf <rasmus@lerdorf.com>
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: willfitch@php.net (Will Fitch)


On Jan 25, 2013, at 11:25 AM, Zeev Suraski <zeev@zend.com> wrote:

>> 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.
>>=20
>> 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.
>=20
> 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.

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

> I think we can actually do it on time for 5.5.0, or with a relatively
> minor delay that might be worth it.  I'm sure most users would prefer =
the
> version to take a bit longer if it comes with an opcode cache right =
off
> the bat.
> There'll most probably be APIs we'd want to merge from APC, but doing =
that
> should be easy - and we can get the good of both worlds.
>=20
> Zeev
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20