Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76435
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CA+9eiLsPg4-QY_M6ddV+5N=e4fddpyw8ux3mwPxrcJMVHM4+mQ@mail.gmail.com>
Date: Mon, 11 Aug 2014 19:09:24 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EBA37E12-4F95-4524-A900-48AB8CDA3674@ajf.me>
References: <D17EB1B8-7A7E-419B-AF55-0ADCAB4CFEB3@ajf.me> <CA+9eiLsPg4-QY_M6ddV+5N=e4fddpyw8ux3mwPxrcJMVHM4+mQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: ajf@ajf.me (Andrea Faulds)


On 11 Aug 2014, at 08:36, Dmitry Stogov <dmitry@zend.com> wrote:

> Hi Andrea,
>=20
> Could you measure the performance impact of function referencing.
>=20
> <?php
> $func =3D "strlen";
> for ($i =3D 0; $i < 10000; $i++) {
>     $func("hello");
> }
> ?>
>=20
> vs
>=20
> <?php
> $func =3D &strlen;
> for ($i =3D 0; $i < 10000; $i++) {
>     $func("hello");
> }
> ?>

On my machine:

    andreas-air:php-src ajf$ time sapi/cli/php ../funcref_a.php
   =20
    real	0m0.043s
    user	0m0.022s
    sys	0m0.008s

    andreas-air:php-src ajf$ time sapi/cli/php ../funcref_b.php
   =20
    real	0m0.023s
    user	0m0.015s
    sys	0m0.006s

I think the reason that function references are faster here is that it =
only has to do the hash table lookup once. If you tried to create a =
reference on each iteration and compared that to just using the string, =
then the string would be faster, as no memory needs to be allocated and =
deallocated for the closure.

> I don't like the "&" syntax a lot, but I understand that it's a =
compromise between readability and implementation complication.

Right. Myself, I=92d prefer to just merge PHP=92s namespaces and have =
$foo =3D func_name; work, but that wouldn=92t work well and would break =
a lot of things.

>=20
> The patch probably misses support for "&self::foo", "&parent::foo", =
"&static::foo=94.

Good catch, I=92ll try and get that implemented. Actually, I wonder if =
having &self::foo be bound to the object using it would be a good idea. =
While I resisted for &$foo::bar (I don=92t support that syntax anyway), =
there might be some merit in it after all. If it would bind for you, you =
could always remove the binding or change it if it would be a problem.

> It also may be improved using run_time cache (this is not important =
now).

That=92s something I wanted to do (might solve the performance problems =
with using & on each iteration), but I=92m not sure quite what the right =
way to implement that is. In particular, what kind of cache (some sort =
of hash map?), how to index it (function name? fully-qualified function =
name?) and where to put it. I suppose I could just add a zval pointer to =
zend_function itself, but that would add eight bytes to every single =
function, which would add up.

Actually, on a related note: Currently & creates a new closure on each =
use, and in PHP closures are compared by identity, not by their value. =
Perhaps we should change that so it checks for the same scope, this_ptr =
and implementation? Having &strlen =3D=3D=3D &strlen would probably be a =
good thing, it=92s the more intuitive thing at least. Comparing the =
this_ptr of the two would be easy, however I have no idea whether you =
could compare the two zend_functions and have it work properly. You =
can=92t just do an =3D=3D in the C code, as closures embed and modify =
the zend_function.
--
Andrea Faulds
http://ajf.me/