Hi Stas,
On Tue, May 12, 2009 at 7:24 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Apologies, I'm not familiar with run-time inheritence in PHP. My
>> understanding was that when a classes source code is compiled, its
>> parent classes must be known. When is this not the case? Must it be
>> known for
Hi Paul:
On Tue, May 12, 2009 at 12:50:12PM +0100, Paul Biggar wrote:
>
> This is what I'm getting at. How can the parent class be changed? I
> can see that it might be deferred, but I don't see how it can be
> changed once it's set.
The decision of which class to extend from can be made at run
Hi!
Apologies, I'm not familiar with run-time inheritence in PHP. My
understanding was that when a classes source code is compiled, its
parent classes must be known. When is this not the case? Must it be
known for the class' first instantiation?
No, the problems here are different. The process
Thanks Dmitry,
I imagined that. I just thought it was already applied, but it's not.
So I spoke a bit with Lukas and he suggested me to revamp this
discussion, since it stopped all of a sudden.
Anyway... once you guys find a final patch, should I expect it at
least commited into HEAD?
Cheers,
On Tue, May 12, 2009 at 12:29 PM, Dmitry Stogov wrote:
>> But I think its fair to say that it has static inheritance - that is,
>> its full inheritance chain is known before it can be instantiated, and
>> it can never be changed after that.
>
> Right, but it has a lot of dynamic issues anyway. E.g
Paul Biggar wrote:
On Tue, May 12, 2009 at 9:43 AM, Dmitry Stogov wrote:
Apologies, I'm not familiar with run-time inheritence in PHP. My
understanding was that when a classes source code is compiled, its
parent classes must be known. When is this not the case?
The parent class may be define
On Tue, May 12, 2009 at 9:43 AM, Dmitry Stogov wrote:
>> Apologies, I'm not familiar with run-time inheritence in PHP. My
>> understanding was that when a classes source code is compiled, its
>> parent classes must be known. When is this not the case?
>
> The parent class may be defined in other f
Paul Biggar wrote:
Hi Stas, Dmitry,
On Tue, May 12, 2009 at 2:01 AM, Stanislav Malyshev wrote:
IHMO it's not static enough. I.e., since PHP is not compiled, we can not
create VD table for the class until runtime inheritance, which means that
the code using this class can use method resoluti
Hi Stas, Dmitry,
On Tue, May 12, 2009 at 2:01 AM, Stanislav Malyshev wrote:
> IHMO it's not static enough. I.e., since PHP is not compiled, we can not
> create VD table for the class until runtime inheritance, which means that
> the code using this class can use method resolution more efficient
Hi Paul,
Paul Biggar wrote:
On Mon, May 11, 2009 at 7:47 PM, Guilherme Blanco
wrote:
What's the status on this one?!
I think it died from neglect. But it was a really good idea.
One question that was raised was:
On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov wrote:
However we can intr
Hi Guilherme,
5.3 is closed for major updates (it is in RC state). I would try to look
into this when we develop a strategy for next PHP version.
Thanks. Dmitry.
Guilherme Blanco wrote:
Hi guys,
What's the status on this one?!
It's an important optimization that should be considered. Save
Hi!
FWIW, since PHP has a static inheritence chain, the best approach
seems to be to build a virtual dispatch table, instead of a hashtable
for functions. However, there might be some esoteric extensions which
make this difficult.
IHMO it's not static enough. I.e., since PHP is not compiled, w
On Mon, May 11, 2009 at 7:47 PM, Guilherme Blanco
wrote:
> What's the status on this one?!
I think it died from neglect. But it was a really good idea.
One question that was raised was:
> On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov wrote:
>> However we can introduce some indirect table as
Hi guys,
What's the status on this one?!
It's an important optimization that should be considered. Save more
than a million method calls on a framework does not worth?
None gave a final word on this subject.
I could not see this commited in 5.3 neither in HEAD.
So...can someone notify me about t
Marcus Boerger wrote:
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 t
Hi!
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.
Well, object can't be constant, so only thing constant can be method
name. We have it in opcode. Everything else
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
>>
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
JFYI: Method calls increased from 3,2 million to 4 million when I have
this patch applied locally.
It's a valuable addiction to core! =)
Short version: Commit!
On Sat, Jan 17, 2009 at 8:26 PM, Hannes Magnusson
wrote:
> (for the fun of it, I am CCing Andi, the CTO and senior VP of Zend)
>
> On S
(for the fun of it, I am CCing Andi, the CTO and senior VP of Zend)
On Sat, Jan 17, 2009 at 21:17, Marcus Boerger wrote:
> Hello Timm,
>
> Friday, January 16, 2009, 9:35:13 PM, you wrote:
>
>> * At [1d], calculate a hash key for the following:
>> - method->name
>> - ce->name
>> - EG(scope)
Hello Timm,
Friday, January 16, 2009, 9:35:13 PM, you wrote:
> Hi,
> in every programming language, method calls are expensive. Especially in
> PHP, which does not spend any effort during compile time to resolve method
> calls their target (and cannot due to the possibility of lazily loading
Hi Timm!
Worth it? I think that's absolute necessity to add this patch, because if it
gives almost 2 times speed boost for typical frameworks, it's just fantastic
(well, the less calls, the less performance boost, but really some monsters
like Zend or CakePHP and others will definitely benefit from
Hi,
in every programming language, method calls are expensive. Especially in
PHP, which does not spend any effort during compile time to resolve method
calls their target (and cannot due to the possibility of lazily loading
classes using include w/ variables). I recently did some performance
23 matches
Mail list logo
