Re: [PHP-DEV] Inline functions
I figured class methods would be a problem, especially if it were implemented at compile time as the compiler wouldn't necessarily know which class it refers to. Curious though, which part of the function call causes the performance hit? I've noticed that the number of parameters it has contributes a large part it. On 28 Apr 2016 7:55 p.m., "Nikita Popov" wrote: > On Thu, Apr 28, 2016 at 8:39 PM, Dominic Grostate < > codekest...@googlemail.com> wrote: > >> That sounds wicked. I look forward to benchmarking it and seeing how its >> done. >> On 28 Apr 2016 6:39 p.m., "Sara Golemon" wrote: >> >> > On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate >> > wrote: >> > > As I understand it, the process by which the call stack is updated and >> > > scope changed, is quite expensive. And from tests I can see that >> > function >> > > calls do actually add a not insignificant overhead to intensive >> > repetitive >> > > tasks. >> > > >> > > So how difficult would it be to get the engine to determine if an >> inline >> > is >> > > feasible, then skip the fcall init, and dump the a functions opcode >> emits >> > > directly into the current scope? >> > > >> > I'm actually working on a proof-of-concept of that already. I've >> > already got basic proxy methods getting inlined, and am working up >> > through expression methods and trying to resolve scoping with $this >> > and non-publics. >> > >> > I'll publish a branch on github when I have something interesting to >> share. >> > >> > -Sara >> > >> > > I also have a proof-of-concept inlining implementation lying around: > https://github.com/nikic/php-src/blob/opt/ext/opcache/Optimizer/inlining.c > > However it only inlines free functions and static methods, not instance > methods, because the latter have the $this being null issue. Another > complication when inlining methods is that we may only know the called > method if it is either private or final, i.e. there is no possibility of it > being overwritten in a child class. > > One tricky issue with inlining is that we need to unset all the variables > of the inlined function after the call, otherwise we may cause issues with > references and destruction order. If these unsets are not eliminated > through DCE they may be pretty expensive (for a larger number of vars). > Furthermore inlining increases the number of variables in the function > (which need to be initialized and destroyed), which may be problematic when > inlining into unlikely branches. (Register allocation for CVs would improve > this). > > Nikita >
Re: [PHP-DEV] Inline functions
On Thu, Apr 28, 2016 at 8:39 PM, Dominic Grostate < codekest...@googlemail.com> wrote: > That sounds wicked. I look forward to benchmarking it and seeing how its > done. > On 28 Apr 2016 6:39 p.m., "Sara Golemon" wrote: > > > On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate > > wrote: > > > As I understand it, the process by which the call stack is updated and > > > scope changed, is quite expensive. And from tests I can see that > > function > > > calls do actually add a not insignificant overhead to intensive > > repetitive > > > tasks. > > > > > > So how difficult would it be to get the engine to determine if an > inline > > is > > > feasible, then skip the fcall init, and dump the a functions opcode > emits > > > directly into the current scope? > > > > > I'm actually working on a proof-of-concept of that already. I've > > already got basic proxy methods getting inlined, and am working up > > through expression methods and trying to resolve scoping with $this > > and non-publics. > > > > I'll publish a branch on github when I have something interesting to > share. > > > > -Sara > > > I also have a proof-of-concept inlining implementation lying around: https://github.com/nikic/php-src/blob/opt/ext/opcache/Optimizer/inlining.c However it only inlines free functions and static methods, not instance methods, because the latter have the $this being null issue. Another complication when inlining methods is that we may only know the called method if it is either private or final, i.e. there is no possibility of it being overwritten in a child class. One tricky issue with inlining is that we need to unset all the variables of the inlined function after the call, otherwise we may cause issues with references and destruction order. If these unsets are not eliminated through DCE they may be pretty expensive (for a larger number of vars). Furthermore inlining increases the number of variables in the function (which need to be initialized and destroyed), which may be problematic when inlining into unlikely branches. (Register allocation for CVs would improve this). Nikita
Re: [PHP-DEV] Inline functions
That sounds wicked. I look forward to benchmarking it and seeing how its done. On 28 Apr 2016 6:39 p.m., "Sara Golemon" wrote: > On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate > wrote: > > As I understand it, the process by which the call stack is updated and > > scope changed, is quite expensive. And from tests I can see that > function > > calls do actually add a not insignificant overhead to intensive > repetitive > > tasks. > > > > So how difficult would it be to get the engine to determine if an inline > is > > feasible, then skip the fcall init, and dump the a functions opcode emits > > directly into the current scope? > > > I'm actually working on a proof-of-concept of that already. I've > already got basic proxy methods getting inlined, and am working up > through expression methods and trying to resolve scoping with $this > and non-publics. > > I'll publish a branch on github when I have something interesting to share. > > -Sara >
Re: [PHP-DEV] Inline functions
On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate wrote: > As I understand it, the process by which the call stack is updated and > scope changed, is quite expensive. And from tests I can see that function > calls do actually add a not insignificant overhead to intensive repetitive > tasks. > > So how difficult would it be to get the engine to determine if an inline is > feasible, then skip the fcall init, and dump the a functions opcode emits > directly into the current scope? > I'm actually working on a proof-of-concept of that already. I've already got basic proxy methods getting inlined, and am working up through expression methods and trying to resolve scoping with $this and non-publics. I'll publish a branch on github when I have something interesting to share. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
