Re: #60038 SIGALRM cause segfault in php_error_cb

From: Date: Mon, 17 Oct 2011 13:28:34 +0000
Subject: Re: #60038 SIGALRM cause segfault in php_error_cb
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-55844@lists.php.net to get a copy of this message
I know, I've just replied with an example to the "Such a performance regression sounds like an appropriate "punishment" to me for deploying bad code ;-)" statement. btw: http://www.tyrael.hu/2011/06/26/performance-of-error-handling-in-php/ http://www.tyrael.hu/2011/10/09/error-suppression-improvements-with-php-5-4/ On Mon, Oct 17, 2011 at 2:49 PM, Ilia Alshanetsky <ilia@prohost.org> wrote: > Unless you are deleting thousands of files in a tight loop, the > overhead involved won't make any difference for your application. > > In general your application is throwing many errors, even "benign" > E_STRICT or E_NOTICE you are already incurring a performance hit. > > On Mon, Oct 17, 2011 at 3:49 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev <smalyshev@sugarcrm.com > >wrote: > > > >> Hi! > >> > >> > >> On 10/16/11 5:54 PM, Sebastian Bergmann wrote: > >> > >>> Such a performance regression sounds like an appropriate "punishment" > to > >>> me for deploying bad code ;-) > >>> > >> > >> By bad code you mean not obsessively checking for stuff that is of no > >> importance to them as programmers and is only required because language > >> implementers decided to go B&D on their users? ;) > >> > >> I personally hate to see all these > isset($foo['bar'])?$foo['bar']**:null. > >> I think it's bad we make people do that. > >> > >> > > and there are cases when you can't avoid triggering errors (like trying > to > > delete delete a while which can be deleted concurrently) so your only > > option is to suppress them and handle the result based on the return > value > > of the statement. > > > > -- > > Ferenc Kovács > > @Tyr43l - http://tyrael.hu > > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu

« previous php.internals (#55844) next »