Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53406
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=nl81LM257rExW7r9cRcIkNbQj2KyUVWRAcTriQO65g/6kEqeQvzvcMMC3HbjiMqrZa
         OJAYyYkK2aIOVVUldDXISFhkW6fFxxFplIczwGVqXdtw2IASTSzOC6E2ZCLf647qjkNy
         +KyLk00F5TMSl6SkJfDmdmHTp/Fl7VnCp1l/Y=
MIME-Version: 1.0
Sender: ekneuss@gmail.com
In-Reply-To: <BANLkTin0GU4HUSx0DS=XxzPpEv6UcRnVtQ@mail.gmail.com>
References: <BANLkTinqTzk_ZQ11SSUiT-kSrkVwBC1Gjw@mail.gmail.com>
	<alpine.DEB.2.02.1106201156250.3774@whisky>
	<BANLkTin0GU4HUSx0DS=XxzPpEv6UcRnVtQ@mail.gmail.com>
Date: Mon, 20 Jun 2011 16:25:49 +0200
Message-ID: <BANLkTimCQTehZhNgJZx_fitKHUbCegctLw@mail.gmail.com>
To: Robert Eisele <robert@xarg.org>
Cc: Derick Rethans <derick@php.net>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Standard constants as part of the lexer
From: colder@php.net (Etienne Kneuss)

Hi,

On Mon, Jun 20, 2011 at 13:12, Robert Eisele <robert@xarg.org> wrote:
> 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
>> {
>> =C2=A0 =C2=A0function true()
>> =C2=A0 =C2=A0{
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0return true;
>> =C2=A0 =C2=A0}
>> }
>>
>> $A =3D 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 funct=
ion
> names. A more general solution would be better, instead of hacking such
> things without deep considerations in an official tree.

Why have them as tokens at all? The optimisation comes from having
specific opcodes, not specific tokens.
We could keep the current tokens, and thus keeping 100% BC, but check
for the content of T_STRING tokens at the parsing level, to dispatch
to specific OPCodes in such cases.

>
>
>>
>> > 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, t=
he
> difference wouldn't that much. But constructs like for($i=3D0; $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
>>
>



--=20
Etienne Kneuss
http://www.colder.ch