Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42704
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Mon, 19 Jan 2009 13:06:41 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1534507524.20090119130641@marcus-boerger.de>
To: Stanislav Malyshev <stas@zend.com>
CC: Timm Friebe <thekid@thekid.de>, internals@lists.php.net
In-Reply-To: <4974440E.3060402@zend.com>
References: <A4BF27E9DF4D4E64AB2164332B12410D@carla> <155749706.20090117211737@marcus-boerger.de> <4974440E.3060402@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Method call improvements
From: helly@php.net (Marcus Boerger)

Hello Stanislav,

Monday, January 19, 2009, 10:12:46 AM, you wrote:

> Hi!

>> Aren't we able to bind these at least partially to the function call
>> opcode, in case we know they are constant? If all is constsnt we could
>> even store the whole lookup in the opcode. Well you'd have to convince
>> Zend to do that because os far they have always been against this
>> approach.

> Err, I'm not sure how can you store in opcode something you don't know - 
> since opcode may be generated well before class or method exists, not 
> speaking about the object of which you know nothing at the time of 
> opcode generation? Same opcode could call entirely different methods of 
> different classes. Am I missing somehing?

Nope. But sometimes we are in a scope where it is always the same thing we
call. Or at leats a one of the three things are constant. And any of them
being constant would help.

>> Also the zend_class_enty lookup in [1c] imo is completely useless. If
>> the zval object would store the class entry and the class entry had a
>> pointer to the handlers then we would save another costly lookup and
>> simply follow a pointer instead.

> having only one handler table per class would make objects less flexible.

How so? Tell me any case where that is different right now?

Right now every member of a class tree (each class derived from a specific
base class) has the same handler table. And that cannot be changed becasue
each of the class members have the same creation/destruction c functions.

The way to change that would be to have several creation functions that
create objects with the same class that have different handlers. While that
works at this level, we would end up in problems where we copy members of
these classes or perform other complex operations. Unfortunately we often
assume that same objects have the same handlers. And last but not least we
already have some code that checks for handlers rather than for classes.
Just because it is faster. My idea would in these cases add one more
pointer indirection but change the other way to simply pointer resolving.
Thus my idea would overall increase PHP speed.

> -- 
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com




Best regards,
 Marcus