On 14/02/13 18:24, Stas Malyshev wrote:
Are optimizations documented?
Not yet AFAIK.
No, but they are pretty self-explanatory. O+ is a _Zend_ extension
rather than a _PHP_ extension and this enables it to exploit extra
hooks (see the tail of ZendAccelerator.c) and specifically follow
through accel_op_array_handler() and the routines in the Optimizer
subdirectory. Essentially this hook is invoked as an epilogue to the
generating of any op_array. What this does is a number of peephole
optimizisations to simplify and NOP out instruction sequences, and the
last pass compresses the code removing dead NOPs to shrink the op_array
-- this is typical of the sorts of things that the optimization passes
of a compiler would do.
And this is a segue into one architectural issue the immediately struck
me on scanning the code: surely there is a natural domain separation
between compilation, image startup/rundown, and execution. (i) is
optimally done once per S/W version, (ii) per request, (iii) per
instruction executed. Surely O+ is currently a hybrid of (i) and (ii)
and whilst this might have occurred for understandable historical
reasons, I question this rationale going forward.
(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.
(B) The O+ opcode cache itself is logically quite separate. It makes
great sense to keep ithis as a Zend extension (given the desire from
some of the dev team to maintain a clear logical separation between the
upper PHP environment and the Zend, Hippop, ... execution environments
that support it). A Zend opcode cache belongs firmly in the Zend world
and shouldn't be a PHP extension.
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.
2) in the treatment of early binding class inheritence: APC include some
reasonably complex logic to back this out; O+ sets a compiler option to
disable this inheritance occurring in the first place, an approach that
APC might want to copy.
