2011/6/20 Derick Rethans <der...@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
>

Reply via email to