We had a little bit of a discussion on twitter about the performance implications of errors in php.

I won’t surprise you as it is (should be) well-known that the error generation and the error suppression is slow. See this blogpost from Derick Rethans: http://derickrethans.nl/five-reasons-why-the-shutop-operator-should-be-avoided.html

So basically @$foo = bar; is slow because:

• an error will be generated and formatted regardless the error_reporting level or the existence of a custom error handler, because you can access the last error through error_get_last and $php_errormsg
• the @ operator only wraps the statement between two ini call: setting the error_reporting to 0, and restoring it to the original value. this is 2 more call to be executed and as you would guess, this means if you have a custom error handler, where you didn’t set the second $error_types parameter in your set_error_handler call, your custom error handler will be executed on the suppressed errors.
• as Derick pointed out, the Zend Engine will generate slower code to the suppressed statements.

I’ve just wrote a little benchmark on the issue, available on github

Basically it executes an assigment in a for loop, either using the string ‘foo’ or the non-existent constant foo, which will fallback to ‘foo’ and trigger a notice (I know, it is not a perfect test, because the constant lookup also has some overhead, but still better and more close to the real life issues than trigger_error()).

I mixed this with using the suppress operator and a custom error handler, here are the results:

tyrael@thor:~/checkouts/php-microbenchmarks$ ./src/testError/test.sh
Executing baseline.php

real    0m1.280s
user    0m1.257s
sys     0m0.023s

Executing baseline+error.php

real    0m7.299s
user    0m7.276s
sys     0m0.022s

Executing baseline+error_handler.php

real    0m1.284s
user    0m1.255s
sys     0m0.029s

Executing baseline+suppression.php

real    0m2.035s
user    0m2.011s
sys     0m0.021s

Executing baseline+error+error_handler.php

real    0m20.405s
user    0m20.377s
sys     0m0.021s

Executing baseline+error_handler+suppression.php

real    0m2.000s
user    0m1.973s
sys     0m0.027s

Executing baseline+error+suppression.php

real    0m8.293s
user    0m8.271s
sys     0m0.021s

Executing baseline+error+error_handler+suppression.php

real    0m20.869s
user    0m20.842s
sys     0m0.020s

• As you can see the overhead of having a custom error handler is almost negligible if it isn’t called.
• The suppression operator adds a small overhead without errors. (~1.6X)
• Having an error without @ or  custom error handler still slow (~5.7X).
• if you have an error and a custom error handler which gets executed, that yields for a ~10X performance loss, regardless of using the suppression operator or not.

So my advices:

• if you see errors in your log, fix them, thats also a performance gain.
• if you use custom error handler, don’t forget to set the $error_types, you can use bitmask like for error_reporting(in our case E_ALL &~ E_NOTICE), or you can pass the error_reporting() to set your handler to the same level as your error_reporting.
• don’t overuse the @ operator, and if you do, always handle the return values of your suppressed statements, or you will suck big time when you have to debug your application (check out the scream pecl extension or xdebug.scream)