> Am 27.02.2015 um 16:12 schrieb Xinchen Hui <larue...@gmail.com>: > > On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand <bobw...@hotmail.com> wrote: >> Am 27.02.2015 um 07:53 schrieb Xinchen Hui <larue...@gmail.com>: >> >> Hey: >> >> On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui <larue...@gmail.com> wrote: >> >> Hey Internals: >> >> I was looking Bob's switch optimization.. >> >> And, I am not against this switch optimization.. >> >> I referring it to show where is my concerns came from >> >> thanks >> >> >> then I start to worry about where is the place optimization should >> goes.. >> >> in generally, PHP is a interpreted language. IMO, it should >> compiler the PHP codes to opcode without any optimization(of course, >> we did some, but they won't change a lots of opcodes which should be >> generated).. >> >> and, since 5.5, we already have opcache bundled in.. >> >> thus, I am proposing a principle, that is: >> >> in the future, we only do optimization in opcache side, and keep >> Zend Compiler without any optimization... considering Zend Compiler do >> things in -O0. >> >> since, optimization always are dangerous.. if we only do them in >> opcache, user can still run them codes with disable opcache, or at >> least disable some optimization level which cause that.. >> >> what do you think? >> >> thanks >> >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ >> >> >> >> >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ >> >> >> Hmm. I'm not sure, but do we really want to have the optimizations depending >> on opcache? >> >> I'd rather shift to slowly adding the optimizations into Zend/, in separate >> compiler steps you can (like in opcache too) enable and disable. >> It's actually a bit weird to have to include opcache just for its >> optimizations. Opcache should do what its name says: the sole task of > Actually, it was called ZendOptimizerPlus...
I know, but still, it's better when an extension only does one thing and not two. >> caching the op_arrays. >> We need to change an extension for nearly every little change in Zend/. That >> shouldn't be the case either. >> >> But just to say, it's not only a minor optimization, in a real world >> stateful parser it makes a difference of a few percent. >> And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. >> (except in case we can determine at compile-time where the switch land, then >> it will be optimized out to a simple JMP) >> > as I said, I am not against this change... I just want to setup a > rule, for where thoese optimization, which could also be done in > opcache. Doing it in opcache would currently need to play with extension-defined opcodes etc. I'd rather not be so invasive in opcache that after the optimizations it cannot run in a normal Zend VM anymore. (also a reason why integrating into Zend would be a good idea) > or, maybe, we could embed opcache(Optimizer) into Zend later... but of > course, it only can happen in next major version... Do we really need a major version for this? It doesn't involve major ABI/API breaks. The compiler step is usually also rather left untouched by most extensions. If we want to do this, we could target 7.1 without major issues. > > thanks >> Bob > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
