Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45369
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>,
 jani.taskinen@iki.fi,
 Ilia Alshanetsky <ilia@prohost.org>,
 'PHP Internals' <internals@lists.php.net>
Message-ID: <48CA00E6-8B42-4FEB-B8DA-6A6D2C3DCD1B@pooteeweet.org>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <4A931054.4080601@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 25 Aug 2009 00:20:03 +0200
References: <4A92D936.2010107@zend.com> <9E8BD3A3-8915-4492-88A9-7EA1A0CF6D86@prohost.org> <4A92DC60.2050606@zend.com> <BE47C3D9-A9FA-45CD-A004-79C8479AFDD3@prohost.org> <4A92EA60.6020605@zend.com> <D3312479-4C3C-4F95-8503-FA0633FF835E@prohost.org> <4A92F13B.9000204@zend.com> <CCC293B8-52C8-4473-8027-6F7B32DC0C3F@prohost.org> <4A92FFA8.1060401@zend.com> <4A9304FC.2000906@sci.fi> <4A930956.9070709@zend.com> <250F0E93-D6F2-490F-9129-598AC6E96500@pooteeweet.org> <4A930D54.6050705@lerdorf.com> <4A931054.4080601@zend.com>
Subject: Re: [PHP-DEV] [patch] error masks
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 25.08.2009, at 00:12, Stanislav Malyshev wrote:

> Hi!
>
>> Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
>> E_NOTICE, whatever, all cause a performance hit even if the
>> error_reporting level is such that they will never show up anywhere.
>> That's what this patch is trying to address.  To write optimal code,
>> they have to be entirely clean of all messages including E_DEPRECATED
>> and E_STRICT.
>
> BTW "cleaning the messages" won't help with performance problems in  
> many cases. Let's suppose you have a code that tries to open some  
> file and if it exists, do stuff (and if it doesn't it doesn't care):
> $fp = @fopen($filename, "r");
> if($fp) {
> // do stuff
> }
> Now if you "clean" it, you do something like:
> if(is_readable($filename)) {
> 	$fp = fopen($filename, "r");
> 	// do stuff
> }
> (and if you don't want race condition there, you still need the  
> if()). Then is_readable and fopen can still can't be guaranteed to  
> not produce warnings if there are open_basedir restrictions or  
> streams involved or FS could change in the meanitime. But now  
> instead of one FS access, you have two - not much of a speedup.


right .. but it should reduce the chances of such errors occurring.  
and like i said .. that is obviously not a speed up, but a slow down.  
but i generally think its wise to encourage people to properly avoid  
error conditions locally, because otherwise sooner rather than later  
you will also no longer see the error conditions which you did not try  
to avoid/handle locally.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org