Re: Zend Optimizer+ Source Code now available

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.