On 29/01/13 08:03, Zeev Suraski wrote:
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.
In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
It's great news that Zend Technologies has decided to open-source
Optimizer+ and given that it is now "the end of next week I look
forward to seeing on this code any day. So thanks to you for this
decision. But now to specific comments on your RFC.
1. Scope of the RFC.
IMO, the RFC covers four separate issues that would be easier to review,
refine and agree if they were kept separate:
a. Zend's decision to OS+. This is entirely within Zend Technology Inc.
and outside the scope of any RFC.
b. The establishment and proper architecture and support of an
opcode-cache interface within the Zend Execution Engine (EE). I will
discuss this below.
c. The decision to include Optimizer+ as a core extension within the
PHP project. However as at the time of this draft only Zend employees
-- and selected Zend-approved 2nd parties who have signed the
appropriate NDAs -- have access to the Optimizer+ source and are
therefore able to review its content. Surely such open access is a
precondition, and it makes no sense to issue an RFC to inform this
decision until at least a few months after the source has been made
widely available for review.
d. The project decision to give any specific opcode-cache extension a
"preferred" status over the alternative opcode-caches. Such a decision
is going to be contentious and -- unless carefully, transparently and
fairly managed -- could lead to conflict within the project. Not good.
So I would suggest that the RFC limit itself to non-contentious claims
relating to one optimizer performance over another.
2. The Detailed Content
The Introduction will need redrafting depending on the proposed /
revised scope of this RFC.
Some form of definition / description of both a PHP opcode-cache and PHP
data-cache needs including in the PHP wiki, but this would sit better
under the https://wiki.php.net/internals hierarchy. This RFC should
simply wiki-link to this page on the first use of [[opcode cache]].
The "Interaction with other extensions and plugins" section is surely
a general statement of requirement that should apply to _any_ opcode
cache and not just Optmizer+, so again this content belongs in separate
Wiki a document with a wiki-link here.
The "Alternatives" is really a "Comparison of APC and Optimizer+" and I
suggest that some points are contentious. The same point applies to the
remaining sections. Surely this sort of comparison only becomes
necessary when we've reach a stage where we are asking voters to choose
a preferred cache, and in that case wouldn't be more appropriate to
agree the selection / assessment criteria first before carrying out a
selection exercise?
3. Why do I suggest an Opcode-Cache interface RFC?
The current Zend 2.x engines provide some hooks which enable the main
opcode caches -- including Optimizer+ and APC -- to deliver accelerated
performance for many application usecases. However, some aspects of
hooking an opcode cache into the Zend EE remain a somewhat of a
compromise. These include:
a. The management of early vs. late binding and the work-arounds that
opcode caches must do to back-out unwanted early binding.
b. Some essential functions that the caches must hook into are not
exposed as hooks (like zend_compile_file) and are sometime implemented
using static functions, leading to the cache needing to reimplement
chunks of zend code.
c. There should be a clear scoping separation of what the (cached)
compile does and what the EE does. An example of where this is mixed is
in the ZEND_INCLUDE_OR_EVAL_xxx_HANDLER functions which resolve paths
and open source files in the case of the xxx_once functions. This file
access is usually unnecessary in the case of cached files as the op-code
cache has already cached the relevant information.
Given that opcode caches are now core to PHP performance, it should be
possible to implement a cache using hooks and interfaces exported
through a Zend header file and without recoding bits of the engine.
Optimizer+ should be an exemplar of such an approach.
Regards Terry Ellison
