On Mon, Mar 2, 2015 at 9:47 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Julien, > > > > Bob's code optimizes things by adding a new OPCode. > > This is different from compiler optimizations. > > > > Compiler optimizations are about changing native, supported OPCode > > structures to other native supported OPCode structure, but that will run > > faster at runtime. > > > > I agree with dmitry that if we separate the optimizer from the OPCode > cache > > (both in OPCache actually), then the one who will use the optimizer but > not > > the cache, will suffer from a drop in performance. This is silly and > should > > be prevented. > > > > We should keep both the optimizer and the cache together IMO, or, we > should > > forbid the optimizer to fire up if no OPCode cache is done after (as the > > optimizer will eat some performances for nothing). > > I disagree. > > All compilation happens interactively (meaning during a request), we > can't afford REALLY complex optimizations (a request taking 5 minutes > would be out of the question) even if we had an opcode cache. > Therefore the optimizations that we include can't be THAT expensive > anyway. Yes, it may double or quadruple compilation time. But we're > talking 10's of milliseconds, not minutes. > > And at that point, why should a CLI script like Composer be forbidden > to benefit from those optimizations? Yes, it make take slightly longer > to compile the script, but the potential benefit of the optimizations > could outweigh any additional compilation cost. > > Makes sense, as soon as the documentation reflects that. Someone seeing a setting called "optimization something" may think about enabling it, and it will speed up his code. Which is not always true, depending on script usage. > > We discussed some time ago to merge OPCache into PHPCore (back to PHP 5.5 > > dev) > > I'm all +1 with that, and for doing that for PHP7.0 > > When PHP 7.0 will be released, we will not support any new feature in > > OPCache for PHP5 branches anyway. > > As OPCache is nowadays not compatible at all with PHP7 (development has > not > > started yet, or I'm not aware of it) , why not merge OPCache to PHP7 > source > > tree (when the time for this will come), still as an extension at first > > time, and keep developing optimizer passes into this (aka : not in > Zend/) ? > > > > I'm also +1 to keep our optimizations into OPCache (into an extension), > and > > allow them to be disabled (like its the case actually), because this > > subject is very hot and sensible. > > We should keep a PHP compiler as-is, and move optimization passes away > from > > it. zend_extension_op_array_handler() callback is designed for that > purpose. > > -1 > > I think that the optimizations should be separated out. Have them go > into a separate extension. Then merge opcache into the engine. I don't > mean copy it, but actually implement it internally. > > Right now, there's a fair bit of duplication and abstraction in the > engine just to enable opcache. A great example is that there are two > separate string interning systems that only share a common API between > Zend and OpCache. There are other areas of opcache where > datastructures are duplicated (or more precisely, information about > them is duplicated). > > So if we merge in the cache to the engine, we can make a far more > streamlined and cohesive compiler. Then, the optimizations can be > enabled by another extension (or perhaps multiple). > > We can even make the optimizations pluggable to enable other > block-level passes to occur (in CFG form, as block_pass.c uses) rather > than require every extension re-implement a lot of logic... > > Overall, I'd prefer to keep the optimizations separate in one or more > clear extensions rather than deeply integrated with temporally-related > code. Then the extensions can decide whether to optimize or not (based > on ini setting perhaps, based on SAPI, cache setting, etc). Besides, > there are more places to optimize than just the oparray (for example, > you can do some optimizations on top of the AST). So having one place > for all of them to go will simply get unwieldy over time. > Yep I see, that makes sense too. This would effectively prevent some code duplications that exists in OPCache, the string interning example is nice of course. Also, you are right saying that now in PHP7 we have an AST, which could considerably ease the optimizations as well. So one extension (or more) for optimizations, and a merge of OPCache into PHP7. I think I can lead that in the next few months, that will be a nice way for me to finally play with ZendEngine 3 ;-) Julien.P
