Since PHP code will run just fine even if it\'s riddled with warnings and notices about undefined indexes and non-static methods being called as static, etc, the question is
I wouldn't quite call it a "significant" improvement for most cases, but running code that does not generate errors of any sort naturally runs faster than code that has to generate a stack trace every other line.
Check out: http://www.noamdesign.com/Web-Design-Blog/15-tips-to-optimizing-your-php-code/ for more information on minor optimizations you can make to your code.
In my own experience, I've found that 95% of code optimization usually deals with how you use your database.
I bookmarked an article in which the author did some benchmarks about that ; unfortunatly, it's in french... but here it is (maybe you'll understand some parts of it) : Ne faites pas d'erreur
And here are the numbers, to help people who don't read french :
error_reporting and display_errors enabled : 5,162.76 msdisplay_errors disabled : 136.18 mserror_reporting disabled too : 117.79 msWhich means that, yes, PHP code runs faster without notices/warnings/errors, even when those are not displayed nor reported.
Derick Rethans says the same thing in this article : Five reasons why the shut-op operator (@) should be avoided (quoting) :
Reason 3: It's slow (part 2)
Whenever PHP generates an error message internally, it's processed and formatted all the way up to the fully formatted message that can be outputted straight to the browser.
Only just before it is displayed theerror_reportingsetting is checked. This however, is not related to the @-operator exclusively.
The error message is just always fully formatted beforeerror_reportingis checked—ordisplay_errorsfor that matter.
Depends on the amount of warnings, but the error handling in PHP is, even when hiding error messages, relatively expensive.
What you'd have to do to estimate the effect is profiling on C level: Install valgrind (assuming you're on Linux) and then run
callgrind /path/to/bin/php /path/to/script.php
this generates a file called callgrind.12345 or so, load this file into an app like kcachegrind and look for php_error_docref0 or php_error_cb to see how much time was spent in the error handler.
Please mind the cachegrind and valgrind docs when doing that and mind that there are many system-dependant variables involved.
EDIT: Oh one more note: I assume that way more time is spent while talking to databases and similar systems. and yet another additional note: fixing notices usually makes the code more robust for future changes so it's a good idea independent from performance.