Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45389
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.220.212 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type:content-transfer-encoding;
        b=seKmct872CZTYJc5MSTAun86tESoUZOiyoPTLP3dDtNR6Tr2YrqRXZoMsMaHXg7VNr
         3/ygUQ12GpGs5JKSd41puSPEetCszVQ7oHHKh6Xpn9/apoVbPTHSUVID4FvkyYg0EddL
         p/7dbhmsC56/fLIt9Vvr4hSBRGewqPtaWlAyo=
MIME-Version: 1.0
Reply-To: RQuadling@googlemail.com
In-Reply-To: <4A9308F3.3050004@lerdorf.com>
References: <4A92D936.2010107@zend.com> <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> <4A9308F3.3050004@lerdorf.com>
Date: Tue, 25 Aug 2009 09:37:25 +0100
Message-ID: <10845a340908250137p117d6a28tb8ecb4ba4def44a4@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: jani.taskinen@iki.fi, Stanislav Malyshev <stas@zend.com>, 
	Ilia Alshanetsky <ilia@prohost.org>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [patch] error masks
From: rquadling@googlemail.com (Richard Quadling)

2009/8/24 Rasmus Lerdorf <rasmus@lerdorf.com>:
> I think we should do something along the lines of what Stas is
> suggesting. =C2=A0The current approach of allocating and sprintf'ing all
> messages regardless of whether they will ever be used for anything is
> painful and a huge impediment to adding informative E_NOTICE and
> E_STRICT messages in the future.
>
> A good example of the benefit of this patch is upgrading a server
> running older PHP code that causes a lot of E_STRICT messages. =C2=A0The
> performance hit can be significant to the point where people may
> downgrade to the older version until they can get around to cleaning up
> the code. =C2=A0Having the ability to properly turn off E_STRICT such tha=
t
> not only are E_STRICT messages not shown, but they also don't eat up
> valuable cpu cycles is something we should have done long ago. =C2=A0It i=
s
> non-intuitive that disabling an error type doesn't also remove the
> performance hit associated with generating that error message.
>
> -Rasmus
>

As an outsider, and from what I've read here, surely the solution is
to simply move the test to determine if an error type is reportable.

If anything, as you _ARE_ all saying that there is a slowdown, I
should maybe file a bug ...

"My @ridden code is really slow, even when I turn off error_reporting!"

So, as an outsider, I'm +1 for speeding up PHP by not running
unnecessary code, but -1 for introducing what is surely quite
obviously an unnecessary ini entry.

<speech style=3DiInspirational">Essentially, it's a bug folks! So let's
fix it!</speech>

Regards,

Richard.





--=20
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling