On 15/02/13 01:59, Stas Malyshev wrote:
(A) The op-code optimization should be integrated into the core compiler
and enabled through a GC(compiler_option) to be available to *any*
opcode cache -- or to the application designer (by exposing these
options through an INI directive.
Most optimizations would not give perceivable benefit unless the
optimized code is run many times. So enabling it without opcode cache
would not produce very big benefit. But yes, in theory these code parts
can live separately and they don't actually need each other.
My point here is that APC and the other opcode caches would also benefit
from these optimizations; they really belong to the compiler and not to
an opcode accelerator. Also yes, this type of optimisation usually has
no net benefit unless #runs / compile is much greater than one, however
there are scenarios (e.g. some nasty iteration intensive batch process)
where taking the hit on optimisation still produces a net runtime saving.
that support it). A Zend opcode cache belongs firmly in the Zend world
and shouldn't be a PHP extension.
I must say I don't understand this conclusion.
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
opcode caching just isn't relevant to a Hiphop environment or even for
that matter a CLR or Java one since this do their own internal caching
anyway.
I also note some interesting difference in approaches between O+ and
APC, say for example:
1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC
patches the op handler and O+ does peephole opcode examination. Both
these workarounds could be avoided by tidying up the scope of work in
the instruction code.
Could you explain this a bit more?
As I posted in a separate not to this list, I've am developing my own
LPC extension, a fork of APC optimized for CLI and GCI use. The dogma
here is that there is no point in opcode caching because "performance
isn't a driver". Well my experience is that performance is always a
driver For example, just because your application is running on a
shared service where UID enforced security must be applied and therefore
some form of scalable per-UID execution environment must be used doesn't
mean that you don't care about performance. LPC still give a ~ 2x
throughput improvement on MediaWiki for example.
I forked and rewrote this cache extension because I couldn't stretch the
APC code to do what I want in a performant manner without breaking it.
It's a demonstrator to help me understand the real issues here and to
get to grips with the minutiae of PHP caching technologies. I just
don't see this ever getting to production, but I must admit that
regressing some of this technologies onto O+ is an option that interests
me because this does hold out the potential of a standard optimiser
extension that supports all mainstream SAPIs.
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
leave examination of the source stream to the compile function? LPC
(like APC though for different reasons) has to rehook the
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLE() handler with a wrapper that
does dynamic code modification to prevent this access occurring. O+
adopts a different strategy.
LPC or APC having to walk through and essential patch over (private)
static constant op_handler vectors is just plain horrible. No, IMO the
Zend architecture should be designed to support caching; it should
present a proper clean interface that extensions such as O+ and APC
implement; and the entire PHP test suite should be capable of being
executed with a cache extension in place and a good cache should not
introduce any test failures.
Sorry for the rant and I hope that I answered your Q :)
