Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45391
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.132.242 cause and error)
Cc: Greg Beaver <greg@chiaraquartet.net>,
 'PHP Internals' <internals@lists.php.net>
Message-ID: <E49F3A54-14EF-460B-8B3F-013944A353C3@prohost.org>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <4A938706.8060600@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 08:36:07 -0400
References: <4A92D936.2010107@zend.com> <4A931A1C.804@chiaraquartet.net> <39F20BFC-DAA0-4403-A52E-62CE5F4CF0FE@prohost.org> <4A9346CA.3070608@chiaraquartet.net> <4B0E7BED-C2AE-4BE5-B6CA-00B810168961@prohost.org> <4A938706.8060600@zend.com>
Subject: Re: [PHP-DEV] Re: [patch] error masks
From: ilia@prohost.org (Ilia Alshanetsky)


On 25-Aug-09, at 2:39 AM, Stanislav Malyshev wrote:

> Hi!
>
>> If you enable error log you would be able to identify errors, even  
>> in legacy code fairly quickly and address them as needed. The speed  
>> increase, by Stas' own admission is very minimal here, I would wager
>
> It's not "very minimal". It's not big overall, but it speeds up  
> operations affected 300-400%. Can you propose many other changes  
> that would speed up any set of opcodes 300% in 10 lines of patch? ;)

I have a few of those in our custom build of PHP, but none of those  
would be ready for general consumption since they take away some of  
PHP's conveniences. There are not many such changes, but a fair number  
are possible.

>> saving memory and eliminating what effectively is a NOOP is a good  
>> idea, making it a configurable, user settable option, will simply  
>> lead to much abuse.
>
> There would be no "abuse" that is not happening today, in almost  
> every production install on Earth. Through the whole scenario you  
> have consistently ignored the fact that we talk about errors that  
> are *ignored* today, and only evidence of their general existence  
> somewhere in the code is the slowdown - which is not measurable  
> anyway, since there's no base for comparison, since there's no way  
> to run _without_ the slowdown without this patch.

You had one really good example from Dan, with respect to  
track_errors, which is real easy to miss. The 3rd party library maybe  
using that functionality to handle certain errors and by doing a  
global ingore errors, you would effectively cut down on error  
information and in some cases make the code thing there is no error.  
There are a few code paths I can see on google where code works  
something like this:

$php_errormsg = null;
some_function();
if ($php_errormsg) {
exit($php_errormsg);
}