Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender)
Message-ID: <4DDAA7BC.20108@sugarcrm.com>
Date: Mon, 23 May 2011 11:30:20 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Drak <drak@zikula.org>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <BANLkTinT_u=9MzMxmX4tyUhyZ=oExQBVjw@mail.gmail.com>
In-Reply-To: <BANLkTinT_u=9MzMxmX4tyUhyZ=oExQBVjw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] call_user_func performance and dynamic code
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> I'd like to ask a question about call_user_func/_array performance and
> the use of runtime variables to call functions and methods from the
> PHP internals perspective.

There are two separate issues here: real-life PHP application 
performance and internal engine performance. If you are interested in 
the former, please do not read the rest of the message, instead please 
read this:

My experience (10+ years of working with PHP) shows that pretty much no 
application ever depends on its performance for such things. Most 
applications aren't even CPU-bound and those who are, their performance 
very rarely depends on how long it takes to make a function call, except 
for very small number of special cases. So unless your profiling of your 
specific application (not an artificial benchmark!) clearly shows this 
to be a problem - it does not matter.

> Many people have blogged about how:-
>
>      $callable = array($object, $bar);
>      call_user_func_array($callable, $args);
>
> is considerably slower than
>
>      $object->$bar($args);

Indeed, the former may take more time, since it involves at least two 
extra things - creating the array and extra function call.
Note however that the semantics of these two is different - in the 
latter case, the called function has one argument which is an array, in 
the former it has unknown number of arguments which are passed as an 
array to call_user_func_array().

> What is the official standpoint from the PHP developers and is there
> are reason to use call_user_func/_array over using variables to
> express the call when considering opcode caching?  What I mean for
> example, is, when using $foo->$bar($args) at runtime, maybe this is
> faster than call_user_func but maybe not if an opcode cache is
> involved (e.g. maybe it cannot cache $foo).  I ask this because things
> like __call() and __get() are also notoriously slow.

Opcode caches do not cache any runtime variables/calls. They cache 
compilation results, which is the result of converting the source to 
opcodes and happens before the code is run. So once include() is done, 
opcode cache has next to no influence on runtime performance - there are 
various optimizations in some implementation, but most of them don't 
make too much difference in real life code, and especially when we 
talking about calling dynamically-resolved functions.

> Also, would there be a reason for certain dynamic notations to be
> slower than others (again with and without opcode caching incolved) -
> a few examples below:

All direct function calls are pretty much the same, array access of 
course adds additional operations which take time too.

> PHP has evolved a lot over the years so it would be nice to know what
> the intention, pros and cons of these methodologies are from an
> official internals point of view and if anything has been changed to
> over time to make these methodologies more efficient.

There's probably no "official" position but I'd say use whatever fits 
your coding style and specific needs, within limits of reason.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227