【发布时间】：2010-12-24 13:01:05
【问题描述】：
由于 PHP 代码运行良好，即使它充满了关于未定义索引和非静态方法被称为静态等的警告和通知，问题是，如果我花时间从我的代码会运行得更快吗？
【问题讨论】：
标签： php performance
【发布时间】：2010-12-24 13:01:05
【问题描述】：
我为一篇文章添加了书签，其中作者对此做了一些基准测试；不幸的是，它是法语的……但是这里是 （也许你会理解其中的某些部分）：Ne faites pas d'erreur
这里有一些数字，可以帮助不懂法语的人：
- 10k 个通知，启用
error_reporting和display_errors：5,162.76 毫秒 - 相同，但禁用
display_errors：136.18 毫秒 - 相同，但也禁用了
error_reporting：117.79 毫秒 - 最后，在修补代码使其不再产生任何通知之后：19.51 毫秒
这意味着，是的，PHP 代码在没有通知/警告/错误的情况下运行得更快，即使这些没有显示或报告。
Derick Rethans 在这篇文章中说了同样的话：Five reasons why the shut-op operator (@) should be avoided（引用）：
原因 3：速度很慢（第 2 部分）
每当 PHP 产生错误时 内部消息，它被处理并 一直格式化到完全 可以是格式化的消息 直接输出到浏览器。
仅在它显示之前error_reporting设置已检查。 然而，这与 @-operator 独占。
错误 消息总是完全格式化 在error_reporting被选中之前——或者display_errors就此而言。
【讨论】：
-
呵呵，发帖后才发现：这是我的第1000个回答^^
-
+1 用于最终测试。通知和警告是您最严重的错误，特别是因为它们不会强迫您立即解决问题。缺少数组索引很容易修复，但很少解决。就个人而言，我将每个通知/警告都视为 E_FATAL。
-
现在，一个问题是错误检查是否不会导致比处理程序更多的延迟。我的意思是：测试存在等。不要误会我的意思：我讨厌警告和通知。我最近得到了这样一个项目，但上面的结果并不能说服我投资。
取决于警告的数量，但 PHP 中的错误处理是，即使隐藏错误消息，相对成本很高。
要估计效果，您必须在 C 级别进行分析：安装 valgrind（假设您在 Linux 上）然后运行
callgrind /path/to/bin/php /path/to/script.php
这会生成一个名为callgrind.12345 左右的文件，将此文件加载到kcachegrind 之类的应用中，然后查找php_error_docref0 或php_error_cb 以查看错误处理程序花费了多少时间。
执行此操作时请注意 cachegrind 和 valgrind 文档，并注意其中涉及许多系统相关变量。
编辑：哦，还有一点需要注意：我认为在与数据库和类似系统对话时，方式会花费更多时间。还有另一个注意事项：修复通知通常会使代码更健壮以应对未来的变化，因此这是一个独立于性能的好主意。
【讨论】：
在大多数情况下，我不会将其称为“显着”改进，但运行不会产生任何类型错误的代码自然比必须每隔一行生成堆栈跟踪的代码运行得更快。
查看：http://www.noamdesign.com/Web-Design-Blog/15-tips-to-optimizing-your-php-code/，了解有关您可以对代码进行的细微优化的更多信息。
根据我自己的经验，我发现 95% 的代码优化通常涉及您如何使用数据库。
【讨论】：