Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53377
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Mon, 20 Jun 2011 12:00:16 +0100 (BST)
To: Robert Eisele <robert@xarg.org>
cc: internals@lists.php.net
In-Reply-To: <BANLkTinqTzk_ZQ11SSUiT-kSrkVwBC1Gjw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1106201156250.3774@whisky>
References: <BANLkTinqTzk_ZQ11SSUiT-kSrkVwBC1Gjw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Standard constants as part of the lexer
From: derick@php.net (Derick Rethans)

On Mon, 20 Jun 2011, Robert Eisele wrote:

> The constants true, false and null are used very often. Unfortunately, 
> every usage of either of these constants invokes a constant lookup. 
> There is no problem with this, constant lookups are fast, but I 
> nevertheless implemented these constants directly in the lexer to 
> avoid these lookups. I'd be glad to see this change in 5.4 as the 
> performance enhancement would be a steal.

Would that not break the following code?:

<?php
class bar
{
    function true()
    {
        return true;
    }
}

$A = new bar;
$A->true();
?>

> I've also added a new OP code to hard-code count() and strlen() which 
> improves the performance by ~800%. This is nice, but limits the usage 
> of count() and strlen() as method name - if no further changes will be 
> made at the parser. I would rather see a optimization for every 
> function call in 5.4.x. I'll take a look at this soon, maybe I can 
> provide a patch for this, too.

Although it's a nice performance increase, I think that breaking 
count() as a method name is not a good idea, as I would assume it's 
used a lot. Even though count() and strlen() can be optimised that much, 
how much does it buy a fully fledged application?

Then there is also the deliberation on whether it's good to go this 
general direction, because I am sure we can make a case to convert every 
function into an opcode perhaps. 

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug