On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch <willfi...@php.net> wrote:

>
> On Jan 25, 2013, at 11:25 AM, Zeev Suraski <z...@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.
> >>
> >> 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.
>
> 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_*)?
>

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...

Julien.Pauli

Reply via email to