Hi,
Optimizations such as 5+7 into 13 really don't get you much. ZEND_ADD (and
other basic opcodes) are not in any way a slow point in a program. And
unfortunately to be able to optimize these you would probably need to put in
an extra pass in the compiler which would probably just slow things down
(unless you have a LOT of these types of additions).
As for the foo() example... This looks very simple however it is actually a
very hard problem that would most likely take far more time and resources to
solve in the compiler then it would to just leave it be. The problem here is
that you need to understand everywhere that $a is assigned a value and its
value is used. The problem becomes very hard in other functions that have
loops and other types of control structures. It really just ends up
becomming a fairly complex mess to solve.
The same can be said about quite a few of the other optimizations you can
think of. On the surface they seem simple (and a few of them actually are)
but most of them are complex... largely do to some of the unique 'features'
of PHP.
In any case, optimization in PHP is not a lost cause. The first thing you
should really do is be using an opcode cache such as APC. Other than that
there are some solutions being worked on. There is Zend Optimizer and there
is pecl/optimizer (which to warn you is probably far from being stable).
There are also a few efforts to compile PHP such as the PHC compiler.
Overall though, more often than not PHP is not the bottleneck of your
program and thus optimization wont get you too much.
- Graham Kelly
On Wed, Jan 13, 2010 at 8:51 AM, Dave Ingram <d...@dmi.me.uk> wrote:
> mathieu.suen wrote:
>
>> Sebastian Bergmann wrote:
>>
>>> Am 13.01.2010 12:18, schrieb mathieu.suen:
>>> Because any optimization, even very simple ones, impose a performance
>>> penalty in the default execution model of PHP which does not use a
>>> bytecode cache.
>>>
>>>
>>
>> For simple optimization I don't think so. Take the simple example:
>>
>>
>> function foo()
>> {
>> $a = 45;
>> return $a;
>> }
>>
>> Here if you don't optimize you are creating a variable. So you put
>> pressure on the gc and the memory.
>>
> But most of the time, the act of optimising will take longer than just
> compiling and running the code, because you have to make decisions about
> whether something can be optimised and the best way to do it. As Sebastian
> said, it only makes sense to invest that time when you're going to be
> reusing the compiler output. Without an opcode cache, PHP just throws away
> the results of the compilation, so there are zero advantages to
> optimisation.
>
>
> Best would be some benchmark.
>> By the way why there is no native bytecode cache ?
>>
>>
>> Only when the bytecode is not regenerated for each execution does it
>>> make sense to invest for time for the then one-time compilation.
>>>
>>>
>>>
>>
>> Sorry I don't understand what do you mean?
>>
> What Sebastian means is that it would only make sense to optimise if you're
> going to cache the output -- otherwise it is simply wasted time that could
> be better spent on other things.
>
>
> Dave
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
