Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53380
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain xarg.org from 209.85.212.42 cause and error)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.02.1106201156250.3774@whisky>
References: <BANLkTinqTzk_ZQ11SSUiT-kSrkVwBC1Gjw@mail.gmail.com>
	<alpine.DEB.2.02.1106201156250.3774@whisky>
Date: Mon, 20 Jun 2011 13:12:58 +0200
Message-ID: <BANLkTin0GU4HUSx0DS=XxzPpEv6UcRnVtQ@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=00221572697e5cdca204a622d1b6
Subject: Re: [PHP-DEV] Standard constants as part of the lexer
From: robert@xarg.org (Robert Eisele)

--00221572697e5cdca204a622d1b6
Content-Type: text/plain; charset=ISO-8859-1

2011/6/20 Derick Rethans <derick@php.net>

> 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();
> ?>
>

Yes, indeed. But as I wrote, we could add T_SIZEOF (symbol for count +
strlen) and T_LVAL (used for constants) as exception for method and function
names. A more general solution would be better, instead of hacking such
things without deep considerations in an official tree.


>
> > 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?
>

I think it depends on the experience of the developers. There are many -
halfway ugly - "PHP optimization" tricks on the net. If these are used, the
difference wouldn't that much. But constructs like for($i=0; $i<strlen($x);
$i++) could get optimized vigorous.


>
> 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.
>

This would make extension development much more complicated.


>
> cheers,
> Derick
>
> grz Robert



> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>

--00221572697e5cdca204a622d1b6--