Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain dmi.me.uk designates 77.68.52.130 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; s=scara-dk; d=dmi.me.uk; c=simple; q=dns;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject:
	references:in-reply-to:content-type:content-transfer-encoding;
	b=I3mciUSvmB9W5BZgkqHIRS0fSlKqGdIZzEJd01AK3TS2RWGh5Gkkob0IsCakwQfrE
	L+XJgVOs7nbq33ffpLgozhqbaqMNwc+8smcDuulknDbSAkVpJmbUWxOEutTzn03anvU
	/N8NB648B75oqVEg5jJGQSv4vniEImZoDes/vAo=
Message-ID: <4B4DCFDA.6090206@dmi.me.uk>
Date: Wed, 13 Jan 2010 13:51:22 +0000
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: "mathieu.suen" <mathieu.suen@easyflirt.com>
CC: Sebastian Bergmann <sb@sebastian-bergmann.de>, 
 internals@lists.php.net
References: <4B4DABED.4060202@easyflirt.com> <hikb2l$q54$1@ger.gmane.org> <4B4DBF40.5040801@easyflirt.com>
In-Reply-To: <4B4DBF40.5040801@easyflirt.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] About optimization
From: dave@dmi.me.uk (Dave Ingram)

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