Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65175
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.220.179 cause and error)
Message-ID: <5102BDDB.4070506@lerdorf.com>
Date: Fri, 25 Jan 2013 09:16:11 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>
CC: Ralf Lang <lang@b1-systems.de>, internals@lists.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>
In-Reply-To: <c2813d225363300a730e2d4009ae3ec1@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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 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.

-Rasmus