Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68978
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1378490503.3656.239.camel@guybrush>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
	<1378490503.3656.239.camel@guybrush>
Date: Mon, 9 Sep 2013 21:50:42 +0200
Message-ID: <CAF+90c_KTSRVThtOuAOBNLSbFJWEuLCGjnrubRJwtu=rYMU3mg@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133458e10cef304e5f8b46c
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1133458e10cef304e5f8b46c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 6, 2013 at 8:01 PM, Johannes Schl=FCter <johannes@schlueters.de=
>wrote:

> From the explanation it sounds like there shouldn't be a high cost, but
> as fcalls are a key operation and already quite slow I wonder if you
> could share some benchmarks. (non-debug-non-tsrm-build)
>
> A good start might be Zend/bench.php. And I understand this is not the
> final patch but good to have the order of magnitude.
>

I didn't see any obvious regressions from Zend/bench.php and this is also
what I would expect: The parts relating to named arguments are hidden
behind optype-specialization of the send opcodes, so those shouldn't affect
perf. There is also a bit extra code in do_fcall_common to handle passing
of additional unknown named params, but that's also just two branches in a
large mix of other code. So it really "shouldn't" impact performance and
judging from Zend/bench.php it doesn't.

I also did a very quick test how a normal call compares to one using named
params. Right now the latter is about 25% slower. But I'm pretty sure this
number can be improved a good bit, e.g. I'm not yet making use of
CACHED_PTR to store the argument number of the parameter.

Nikita

--001a1133458e10cef304e5f8b46c--