开发者

Does php run faster without warnings?

开发者 https://www.devze.com 2022-12-13 09:13 出处:网络
Since PHP code will run just fine even if it\'s riddled with warnings and notices abo开发者_Python百科ut undefined indexes and non-static methods being called as static, etc, the question is, if I spe

Since PHP code will run just fine even if it's riddled with warnings and notices abo开发者_Python百科ut undefined indexes and non-static methods being called as static, etc, the question is, if I spend the time to remove ALL notices and warnings from my code will it run significantly faster?


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 :

  • 10k notices, with error_reporting and display_errors enabled : 5,162.76 ms
  • same, but with display_errors disabled : 136.18 ms
  • same, but with error_reporting disabled too : 117.79 ms
  • and, finally, after patching the code so it doesn't produce any notice anymore : 19.51 ms

Which 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 the error_reporting setting is checked. This however, is not related to the @-operator exclusively.
The error message is just always fully formatted before error_reporting is checked—or display_errors for 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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消