Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65178
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain zend.com does not designate 209.85.219.48 as permitted sender)
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> <5102BDDB.4070506@lerdorf.com>
In-Reply-To: <5102BDDB.4070506@lerdorf.com>
MIME-Version: 1.0
Thread-Index: AQH5KhtP6VxxLAoJObFXtxoIw+gBzgJTObh3AnFb11YDa6R5KAFZ2VOEAfpcKa4Ci32xQpeTbGxw
Date: Fri, 25 Jan 2013 19:30:45 +0200
Message-ID: <0f4aae0765b562c733e9c78fa46495a2@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Ralf Lang <lang@b1-systems.de>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
> Sent: Friday, January 25, 2013 7:16 PM
> To: Zeev Suraski
> Cc: Ralf Lang; internals@lists.php.net
> Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
>
> On 01/25/2013 08:25 AM, Zeev Suraski wrote:
>
> > 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 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.
>
> I would be ok with that. The goal here is opcode cacheing in core. How we
> get
> there is less important. The one thing we can do bringing an old codebase
> into
> core is to clean it up quite a bit since we'd know the target version. All
> the ifdefs
> for older versions can go away, and some of the tricks that need to be
> done
> could be shuffled into the compiler/executor to streamline things.

I agree. It would probably make sense to only maintain it for 5.5.0, or
perhaps both 5.4.0 and 5.5.0 since those will be the two supported versions
for years to come.  No real point in supporting 5.3 and earlier, and I bet
we can clean things quite a bit with such an assumption.  Tighter
integration may also prove helpful.

> I am also not worried about userspace compatibility for things like
> apc_store/fetch. Any software written to make use of that already has
> conditional checks around it plus that feature needs a serious re-think
> anyway.
> Sharing a lock with op_array handling really doesn't scale.

Ideally I think we'll want to have some sort of continuity, so we could
either keep APC available as a data-cache-only extension (either in core or
outside), or merge this code together with Optimizer+.  One other thing we
may consider is our data caching component, which is already decoupled from
Optimizer+, and exposes APC-compatible APIs - we can look into opensourcing
it as well (it's already free today).

Zeev