On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand <bobw...@hotmail.com> wrote:
> > > 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. > I think so. This may affect some binary interface but should be completely transparent for users. Thanks. Dmitry. > > > > > thanks > >> Bob > > > > > > > > -- > > Xinchen Hui > > @Laruence > > http://www.laruence.com/ > > Bob > >
