On Wed, Jun 3, 2015 at 4:29 PM, Sara Golemon <p...@golemon.com> wrote:
> > > On Jun 3, 2015, at 00:50, Michael Wallner <m...@php.net> wrote: > > > >>> On 03 06 2015, at 05:30, Bishop Bettini <bis...@php.net> wrote: > >> > >> My question though is on relative times. Method call overhead is > >> consistently 50% to 150% over a direct call. Is my experiment invalid, > or > >> is this overhead expected? Is the overhead in the allocation, > >> deallocation, GC? > > > > I’suggest you use a tool like valgrind’s callgrind (and visualize with > e.g. kcachegrind). > > > I'd also take variable function calling out of the picture (or at least, > have it as a separate dimension). Normal applications make pretty spare > use of variable functions (compared to actual direct calls), whereas your > benchmark uses them exclusively. So you've explicitly chosen the most > pessimistic path, and an unrepresentative one. > Yep, as I explain in [1] several [2] articles, direct calls are more efficient that variable ones, which makes the engine analyze your variable and look up for the function at runtime (whereas its done at compile time when direct call). Methods are heavier to trigger, because the engine needs to find the class, then to find the method in the class, to finally use it. The compiler can't pre-compute things, because the class may not exist yet and be rutime-autoloaded, which adds flexibility to the language, but also prevent us from optimizing things too deep. The lookups in method calls are done only the first time, those lookups are cached in the VM frame for reusage later. You may have a look at ZEND_INIT_STATIC_METHOD_CALL handler if you want to see what happens (for static calls). For functions, if the function is known at the time its called, and if the call is direct, then the process is fully optimized. [1] http://jpauli.github.io/2015/02/05/zend-vm-executor.html [2] http://jpauli.github.io/2015/01/22/on-php-function-calls.html Julien Pauli > > -Sara > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
