Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92862
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.68 as permitted sender)
MIME-Version: 1.0
Date: Thu, 28 Apr 2016 09:21:21 +0100
Message-ID: <CAFKaYMpaSLaKd0avU_41UHYt3taovmNYXhRenz+XoZFUZbkf-Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1145e65423e0b60531873664
Subject: Inline functions
From: codekestrel@googlemail.com (Dominic Grostate)

--001a1145e65423e0b60531873664
Content-Type: text/plain; charset=UTF-8

Something in Dmitry's attribute RFC caught my attention.  There is an
example implying inline functions indicated by an attribute.

I know that was only a potential use case for an extension. But it made me
wonder how much that could improve PHPs performance if we actually had it.

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?

--001a1145e65423e0b60531873664--