Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92894
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFKaYMq+s0w4uT-9tKpBybPAri0T0KaFmJdti1oUbptGrt3NiQ@mail.gmail.com>
References: <CAFKaYMpaSLaKd0avU_41UHYt3taovmNYXhRenz+XoZFUZbkf-Q@mail.gmail.com>
	<CAESVnVrg3vObe-52kGs6+oTsY883_7iuA2G2tAFg9RC69hhTvA@mail.gmail.com>
	<CAFKaYMq+s0w4uT-9tKpBybPAri0T0KaFmJdti1oUbptGrt3NiQ@mail.gmail.com>
Date: Thu, 28 Apr 2016 20:55:49 +0200
Message-ID: <CAF+90c-U8_TF0JyceTgfamvcjTQTsPcZ-LJApFKEW6CUqZePoQ@mail.gmail.com>
To: Dominic Grostate <codekestrel@googlemail.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f43dc240513053190135f
Subject: Re: [PHP-DEV] Inline functions
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113f43dc240513053190135f
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 28, 2016 at 8:39 PM, Dominic Grostate <
codekestrel@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" <pollita@php.net> wrote:
>
> > On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate
> > <codekestrel@googlemail.com> 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

--001a113f43dc240513053190135f--