Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55844 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25654 invoked from network); 17 Oct 2011 13:28:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Oct 2011 13:28:39 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.174 as permitted sender) X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.213.174 mail-yx0-f174.google.com Received: from [209.85.213.174] ([209.85.213.174:34435] helo=mail-yx0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3D/45-27630-58D2C9E4 for ; Mon, 17 Oct 2011 09:28:37 -0400 Received: by yxp4 with SMTP id 4so4203370yxp.33 for ; Mon, 17 Oct 2011 06:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qd8pojW49KxOtdS34jtbcIyepvjhx6z5h9ALYHJYo8M=; b=pFPuOFrVxO/B/J1GM45U1ab6bcfRIlasoAtWDf31SAJ+j0G8sYXnoH116VyOu8Rl3c KV4l13xqMhzrv40ua7NlclchoBSYYsGftDWHA41RCthdpgvL7JDYqz3t767Ty2VUHWSI 1UPFHFm/23VZjV4k/tNrV9pOXwkqQIC3CcRrg= MIME-Version: 1.0 Received: by 10.236.182.67 with SMTP id n43mr7737263yhm.104.1318858114278; Mon, 17 Oct 2011 06:28:34 -0700 (PDT) Received: by 10.147.125.13 with HTTP; Mon, 17 Oct 2011 06:28:34 -0700 (PDT) In-Reply-To: References: <4E95AB4E.6040302@sugarcrm.com> <4E9B7CDF.4090106@php.net> <4E9BD142.8060806@sugarcrm.com> Date: Mon, 17 Oct 2011 15:28:34 +0200 Message-ID: To: Ilia Alshanetsky Cc: Stas Malyshev , Sebastian Bergmann , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=20cf3056396f69257f04af7e95cd Subject: Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb From: tyra3l@gmail.com (Ferenc Kovacs) --20cf3056396f69257f04af7e95cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 wrote: > > On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev >wrote: > > > >> Hi! > >> > >> > >> On 10/16/11 5:54 PM, Sebastian Bergmann wrote: > >> > >>> Such a performance regression sounds like an appropriate "punishmen= t" > 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 languag= e > >> 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=C3=A1cs > > @Tyr43l - http://tyrael.hu > > > --=20 Ferenc Kov=C3=A1cs @Tyr43l - http://tyrael.hu --20cf3056396f69257f04af7e95cd--