Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <51164EA2.2000800@ellisons.org.uk>
Date: Sat, 09 Feb 2013 13:26:58 +0000
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>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <5d21b42656d49b4a71d9f808541bd745@mail.gmail.com>
In-Reply-To: <5d21b42656d49b4a71d9f808541bd745@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080602010801070609010107"
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
From: Terry@ellisons.org.uk (Terry Ellison)

--------------080602010801070609010107
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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

--------------080602010801070609010107--