Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65882
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender)
Message-ID: <511E8EC6.7080408@sugarcrm.com>
Date: Fri, 15 Feb 2013 11:38:46 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Terry Ellison <Terry@ellisons.org.uk>
CC: PHP internals <internals@lists.php.net>
References: <e8aaa4ce59a801e53c6abc9d287d1859@mail.gmail.com> <511BFC81.8020400@oracle.com> <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com> <CAOc_q_wT5Umo1c2C-H33+n79sBRa64a1BRZYh1bHj3NdRer7jg@mail.gmail.com> <511D2BD6.2090903@sugarcrm.com> <511D93E3.3010707@ellisons.org.uk> <511D967D.6040604@sugarcrm.com> <511E86F8.5040807@ellisons.org.uk>
In-Reply-To: <511E86F8.5040807@ellisons.org.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Put simply PHP extensions should only reference the APIs exposed in the
> php headers.  Zend has its own interface and extensions and since a Zend
> Opcode cache is SO intimately coupled with the Zend environment it makes
> sense to use a Zend extension to implement this.  The whole idea of

OK, I see. Well, the difference between Zend ext and PHP ext is not that
big, it's mostly just loading order and couple of hooks, of which I
think O+ really uses only op_array_handler, and this for optimization's
benefit - so if you separate optimization, I think O+ can live as PHP
extension, maybe. Not sure if it's worth the trouble though.

> Now to ZEND_INCLUDE_OR_EVAL.  My rationale here is that if the admin has
> specified a stat=0 (or equiv) option then this is a statement that the
> caches content and metadata can be trusted so there is no point in
> examining or reading source files.  However, in the case of the xxx_once
> variants of this instruction, the
> ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in
> the case of first load opens the source stream.  Why?  Why not just

I see what you mean. I can't think of a reason why they are combined
now. Before realpath cache and separate path resolution functions that
was the only way to handle paths properly - since path can be resolved
differently by different streams, etc. I think giving a fresh look to
this API and seeing if we can improve it for 5.6, etc. would probably be
a good idea.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227