> Am 09.03.2015 um 11:24 schrieb Derick Rethans <der...@php.net>: > > On Fri, 27 Feb 2015, Xinchen Hui wrote: > >> Hey Internals: >> >> I was looking Bob's switch optimization.. >> >> 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? > > I think it's a very sensible approach. I would however like to see this > sort of 'experimental' optimisations to be also possible through an > extension. I think some of Sara's? AST hooks might help here? > > cheers, > Derick
Hey Derick, I don't think this would work. The AST hooks allow changing the AST, but they wouldn't allow emitting opcodes based on AST. (We can manipulate the AST, but we can't substitute the function which compiles e.g. a switch-AST / zend_compile_switch) The only thing which would work here is changing the opcodes after the compilation, but that's a hack. That's going to opcache way and implies that we have to do a) full-op_array walks and b) messing around with jump-offsets. Also, when we do this in an ext, we must assume that we don't run this and opcache simultaneously etc. (because opcache relies on ZEND_SWITCH opcode to *not* exist and the ext would have to rely on the specific order in which instructions are emitted by the compiler) The way I did it here is IMO the only clean way to do it. Feel free to prove me wrong, though ;-) … Also, we could do the optimization only in opcache, but this really wouldn't ease integration of this particular optimization... I'd rather like to see specific optimizations very close to the Engine also in the Engine or in some subdirectory of Zend. Instead of an ext. Releases anyway already are dependent on opcache keeping up with the engine. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
