[SOLVED] Do minor errors/notices that are not reported or displayed hurt performance?

[sKunKbad]

Does php use any memory, and thereby slow down a script, if there are minor errors/notices that are not reported or displayed? For instance, if a script was very large, and worked fine with error reporting and display errors off, but had a lot of errors.... a couple hundred.... would there be a performance loss?

[Highlander]

No, there will not be any performance losses, but why do you run a script with a lot of errors? Why not fix the errors?

[PFMaBiSmAd]

Yes there is a small performance loss for each statement that generates an error.

 

Every php statement that generates a notice, warning, or error, even if the reporting, logging, or display of those errors is turned off, takes about 10 times longer to execute because php must still go through the error handler to figure out what to do about the error. And don't use the @ because that causes a small performance loss for each one just because the @ is present, even when there are no errors.

 

The reporting of the error or the logging/display of the error is just the last step that php goes through for each error that it encounters. The error_reporting setting just affects what errors are reported (displayed or logged) and the display_errors setting just determines if the error messages are output to the browser.

 

For example, consider what happens when you don't quote an array index name and/or don't use isset() to test variables that might not exist -

 

$_POST[some_name]

 

Php must first check the table of all the defined constants, both user and php's builit in constants, to find the value of the constant some_name. When it does not find that entry in the defined constants, a Notice level error is produced. If the error_reporting level is set to hide notice errors, the actual notice message is not produced. Php then assumes you meant to use quotes around some_name and checks the $_POST array index names for 'some_name'. If it does not find that index name, such as when you don't use isset() to test for a variable that might not exist, another Notice level error is produced. Php then figures out that it must supply a NULL value for the variable that was referenced.

 

Well written and well tested code should not generate any errors, warnings, or notices for expected conditions during its' normal execution. You should only see errors, warnings, or notices for unexpected conditions, such as a legitimate visitor entering a valid but unexpected value in a form, or a hacker feeding your code all kinds of unexpected data in an attempt to break into your script.

 

You should always have error_reporting set to E_ALL and log_errors set to ON (you want to know if, when, or how a hacker breaks in or if a visitor enters a value in a search form that should have succeeded but instead caused a query to return an error... so that you can find and fix the problem.) For a development system display_errors should be set to ON and for a live server display_errors should be set to OFF.

[Highlander]

Yea, silly me, haven't had my coffee yet

 

Of course it will take some computing time for each error

[sKunKbad]

PFMaBiSmAd,

 

The reason why I was asking was that I use a framework, and it has many instances where the code tries to return a dynamic expression or a result of the new operator. In the php manual page for Returning References, it is clear that with the particular branch and version of php that I am using (5.2.6), that an E_NOTICE error is issued. When I did a search through my files in this framework, I found nearly 130 instances of "=&". It didn't take long, and I removed the ampersands, and I really felt that there was a performance increase, but I didn't know if this was real, or if I was imagining that it was loading faster. Of course not all of the 130 instances of "=&" would cause an E_NOTICE error to be issued on every request, because not every request would use every class in the framework, but I'd expect that on some requests that anywhere from 25 to 50 instances of "=&" would have triggered errors. So, while the performance increase may not be huge, perhaps my sense that my site is loading faster is not just my imagination.

 

Thanks for your answer. It was long, and I appreciate your thoroughness.

[Daniel0]

Sounds like you need a better framework.

[sKunKbad]

Sounds like you need a better framework.

 

It is CodeIgniter. Talk on their forum is that a new release due out soon will fix this. They pride themselves on being php4 compatible, which is the reason this code is the way it is. I didn't feel it was appropriate to ask this question on their forum, because I wanted a truly unbiased response, and not just a feel-good answer.

[PFMaBiSmAd]

They pride themselves on being php4 compatible

 

I would not brag about that. The end of life of php4 was Dec. 31, 2007 and security fixes for it stopped in Aug. 2008.

[sKunKbad]

I would not brag about that. The end of life of php4 was Dec. 31, 2007 and security fixes for it stopped in Aug. 2008.

 

Yeah, I hear what your saying. I don't need the php4 support, and I'm not sure why they would support it, but they must have a reason.

[corbin]

Their reasoning is probably that some people will be stuck with PHP 4 (client won't move host or something), so they'll need a framework that supports it.  In other words, I think they're hoping people will choose their framework just because it's PHP 4 compatible.  Or maybe they're just the types who like to keep as much backward compatibility as possible, even if pointless.