On 05/09/2013 01:02 PM, Pierre Schmitz wrote:
Hi,
I am testing PHP 5.5 atm and how we can package it for Arch Linux and
provide an upgrade path for users. The RC1 looks pretty solid so far.
As the new opcache does not provide a user cache to store custom
variables, I would be glad if you could clarify what the best migration
from 5.4 would be.
* Is APC basically dead and wont support PHP 5.5?
* Should APC users switch to opcache and APCu? (with APCu replacing the
APC package)
For PHP application developers:
* Regarding APCu: it provides the old PHP interface function as well as
their own apcu_* functions. They are aliases right now. Should
application developers think about switching to the apcu_-API as new
features will be available only here?
Bonus question:
* Right now very similar functionality is provided by APCu, XCache,
WinCache, YAC etc.. Are there plans to include such functionality inside
PHP in future to make application developers life a little easier? At
least a common API would be great. There were several bugs in
applications as these modules behave a little different regarding return
values etc..
Greetings,
Pierre
Working backwards: I personally don't see a reason for user caches to be
in the core, not least of all there are multiple solutions, all suitable
and some still maintained. The reason I think it's not really a core
feature is that caching of user variables is something that must be
explicit in an application, whereas opcode caching and the optimization
that opcache performs should be a standard part of the compilation stage
of execution, so fits better in the core.
There's no merit to the argument that opcache and APC/YAC/whatever could
share shm logic: the kind of implementation that APC(u) and opcache need
are very different, right now they both have a suitable allocator.
Furthermore, YAC implements (a very clever) completely different way of
allocating shared memory, which should be tested on it's own merit in
the real world before I consider implementing it's allocator in APCu.
By default, APCu builds in an APC-compatible manner, emulating the old
functions for APC, no change should be required to run legacy code
relying on APC.
New features, if they are written, will not be included in the APCu
codebase, instead, APCu exposes all of it's API to other extensions,
which allows any future features to be written and maintained completely
separately, which I think to be a better solution as APC is in such
heavy use.
Very few people are able to helpfully maintain an opcode cache, the idea
of including opcache in the core, or one of the ideas/benefits, is that
everyone able can concentrate on one solution, implicitly APC will fall
by the wayside where opcode caching is concerned. However, it is
possible to run APC and opcache side by side by fiddling with ini
settings, I can't really say if this is advisable or not, a possibility
all the same.
I think that's everything ...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
