Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45356
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain m.gmane.org designates 80.91.229.12 as permitted sender)
To: internals@lists.php.net
Date:  Mon, 24 Aug 2009 16:33:23 -0400
Lines: 32
Message-ID: <h6utek$mgt$1@ger.gmane.org>
References:  <4A92D936.2010107@zend.com>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
In-Reply-To: <4A92D936.2010107@zend.com>
Sender: news <news@ger.gmane.org>
Subject:  Re: [PHP-DEV] [patch] error masks
From: rabbitt@gmail.com ("Carl P. Corliss")

Stanislav Malyshev wrote:
> Hi!
> 
> I've implemented a patch that allows to "mask" certain types of errors - 
> i.e. make PHP engine completely ignore them. Now even if the error is 
> not reported, it passes full cycle through message string creation, all 
> allocations on the way, etc. even though ultimately the result of it 
> will be thrown out. So I offer a way to make unwanted errors just 
> disappear.

I know I'm a nobody here but, I think this is a really important change. 
I have worked in a couple of different companies where we have 
specifically turned turned down the error log noise in our production 
environment but kept them turned on fully (E_ALL | E_DEPRECATED) in our 
dev/staging environments.

While our production environments were technically a bit quieter 
log-wise, there was definitely no apparent performance benefit aside 
from saving having to write to the logs. In fact, during our transition 
from 4.x -> 5.x, we noticed a marked slowdown related to generation of 
E_STRICT messages even when E_STRICT was disabled - which I only 
realized through stepping through the source via gdb was because it was 
still going through the motions of creating the messages even though 
they were discarded later.

Again, I know I'm nobody here but, I really hope you find this patch 
worth committing - I know I would.

Thanks for listening,

--
Carl P. Corliss