2009/8/24 Rasmus Lerdorf <ras...@lerdorf.com>: > I think we should do something along the lines of what Stas is > suggesting. The 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. The > 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. Having the ability to properly turn off E_STRICT such that > 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. It is > 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=iInspirational">Essentially, it's a bug folks! So let's fix it!</speech> Regards, Richard. -- ----- 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=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
