On Fri, Feb 27, 2015 at 6: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?
>

The big practical problem. That without opcache optimizations are executed
on each request.
This means that they may require more time to work, than the gain from
bytecode improvement.


> 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
> caching the op_arrays.
> We need to change an extension for nearly every little change in Zend/.
> That shouldn't be the case either.
>

Yes. Opcache is extremely depends on engine. Moving optimizer from opcache
to ZE may be a good idea.
Technically it's possible, but I'm not sure when and how it should be done.
I think optimizer need to be refactored as well, but this is only for 7.1
probably.


> 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)
>

Your ZEND_SWITCH optimization makes sense.

Unfortunately, implementation is a bit messy (not intuitive).
The biggest problem that it doesn't fit with existing Optimizer.
For now I don't know how to change Control Flow Graph representation and
corresponding pass to support ZEND_SWITCH.

Thanks. Dmitry.


>
> Bob
>

Reply via email to