On Mon, 25 Apr 2016, 21:07 S.A.N, <ua.san.a...@gmail.com> wrote:

> 2016-04-25 20:56 GMT+03:00 Rowan Collins <rowan.coll...@gmail.com>:
> > S.A.N wrote on 25/04/2016 18:49:
> >>>
> >>> There's not really a huge connection between opcode caching and
> >>> optimization
> >>> >(OpCache) and shared memory data caches (APCu, memcached, etc), so I
> >>> > don't
> >>> >think there's any particular logic to calling such functions
> "opcache".
> >>> >
> >>> >So I guess the question becomes: "should APCu be made part of core?"
> I'm
> >>> > not
> >>> >aware of anyone having proposed that, so don't know if there are
> strong
> >>> >feelings for or against such a thing.
> >>
> >> Yes, there are a lot of libraries to work with shared memory, but why
> >> should they if there OPcache in core PHP?
> >> Functions get, set key values will be useful and in demand.
> >
> >
> > Because different situations call for different functionality. If the
> only
> > reason not to use APCu was the need to install a PECL extension, then
> nobody
> > would have implemented a PECL extension for Memcache, or Redis, etc.
> >
> > Storing data in PHP's shared memory has several downsides - for instance,
> > inability to share with CLI / services built in other languages,
> > non-persistent across server restarts, not shareable across instances,
> etc.
> > For you, these may not be an issue, but to say that "if APCu
> functionality
> > was in core, nobody would need any other memory cache" is somewhat naive.
>
> I am not against third-party libraries, I want to have this
> functionality out of the box, it seems to me correct to make these
> functions in OPCache, instead of adding  Apcu to PHP core, IMHO...
>

A little history lesson - combining an opcode cache and data storage is one
of the reasons APC died - it got too complex and too convoluted in the end.
Yes, there were other reasons too, but this one was one of the big one.

Getting that functionality into the core is not bad idea, but never ever
ever mix it with the opcode cache. Keep them separate.

>

Reply via email to