Standard constants as part of the lexer View as Markdown

Hi,

2011/6/20 Derick Rethans derick@php.net

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.

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, 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

--
Etienne Kneuss
http://www.colder.ch

Hi!

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.

If you're microoptimizing, you should not do this unless $x is a dynamic
string, so I'm not sure messing with strlen is the right way to improve it.

Also, I really do not like splitting strlen()/count() code into two
places. It hurts maintainability and will lead to weird BC problems. I'm
not sure if the optimization is worth it, but if it is, it should be
done differently, with only one code for any strlen()/count()
implementation.
Also, I don't see why strlen/count should share an opcode if there's
absolutely no common implementation code between them.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227