说真的，我应该写糟糕的PHP代码吗？

我最近在做一些PHP工作，在我看到的所有代码中，人们倾向于使用很少的方法。（他们也倾向于使用很少的变量，但这是另一个问题。）我想知道这是为什么，我发现这条注释“一个带有一个参数和一个空函数体的函数调用与执行7-8个$localvar++操作的时间差不多。一个类似的方法调用当然是大约15个$localvar++操作”

即使PHP页面已经编译和缓存，这是真的吗？为了提高效率，我应该尽量避免使用方法吗？我喜欢在代码块重复的地方用方法编写组织良好、可读的代码。如果有必要编写没有方法的平面代码，是否有任何程序将“内联”方法体？这样我就可以编写好的代码，然后在部署之前把它修改一下

顺便说一下，我一直在看的代码来自Joomla 1.5内核和几个WordPress插件，所以我假设他们都知道自己在做什么

---

注意：我很高兴大家都跳到这个问题上来讨论优化一般来说，但实际上我们讨论的是解释语言中的优化。至少我们在谈论PHP这一事实的一些暗示会很好。

您应该看到对这个问题的回答：

总结一下大家的共识：除非你（通过测试/评测）知道你的性能需要在某个特定领域得到解决，否则可读性就更重要了。

你需要多少“效率”？你测量过了吗？过早的优化是万恶之源，而没有度量的优化总是过早的

还请记住

优化俱乐部的第一条规则是，你不优化

优化俱乐部的第二条规则是，不进行测量就不进行优化

如果您的应用程序运行速度比基础传输协议快，则优化结束

一次一个因素

没有marketroid，没有marketroid时间表

只要有必要，测试就会继续进行

如果这是您在优化俱乐部的第一晚，您必须编写一个测试用例

---

在99%的情况下，您最好担心代码的可理解性。编写易于测试、理解和维护的代码

---

在性能非常关键的少数情况下，像PHP这样的脚本语言不是您的最佳选择。毕竟，PHP中的许多基本库函数都是用C编写的，这是有原因的。

就我个人而言，虽然函数调用可能会有开销，但如果这意味着我只编写一次代码（参数化），然后在85个地方使用它，那么我就远远领先了，因为我可以在一个地方修复它

---

<>脚本语言倾向于让人们认为“足够好”和“工作”是编码时考虑的唯一标准。

当然，你不应该编写糟糕的PHP代码。但是一旦你写了一些不好的东西，你可能总是用性能作为借口：-）

这是过早的优化。虽然函数调用的成本确实高于增加局部整数变量的成本（几乎所有东西的成本都高于此），但与数据库查询相比，函数调用的成本仍然非常低

另见：

---

PHP的主要优势在于它可以快速、轻松地获得一个可用的应用程序。这种优势来自于编写松散（糟糕）代码的机会，并且它仍然以某种预期的方式运行

---

如果您需要节省一些CPU周期，那么PHP就不是您应该使用的。当PHP web应用程序性能不佳时，很可能是由于查询效率低下，而不是代码执行速度太慢。

回答您的第一个问题，是的，这是正确的，对于编译的操作代码也是正确的。是的，您可以通过避免函数调用来加快代码速度，除非在极端情况下，由于代码重复，代码变得过大

您应该做自己喜欢的事情“我喜欢在代码块重复的地方用方法编写组织良好、可读的代码。”

---

如果你要犯下这种可怕的暴行，删除所有函数调用，至少要使用一个分析器，只对10%重要的代码进行分析。

如果你对效率的每一点都那么担心，那么你到底为什么要使用脚本语言呢？您应该使用更快的语言（在此处插入您最喜欢的编译语言）进行编程，可能会产生更多、更少的可读代码，但它会运行得非常快，而且您仍然可以追求最佳编码实践

---

说真的，如果你是为了提高运行速度而编写代码，你根本不应该使用PHP。

一个微观优化如何导致宏观减速的例子：

如果您认真考虑手动内联函数，请考虑手动展开循环。

JMP非常昂贵，如果您可以通过展开消除循环并消除所有条件块，那么您就可以消除仅在CPU缓存中查找而浪费的所有时间

运行时的变量扩充也很慢，从数据库中提取数据也很慢，所以您也应该将所有数据内联到代码中

实际上，仅仅为了执行代码和向用户复制内存而加载一个解释器是非常浪费的，我们为什么不预先计算所有可能的页面，并将每个页面存储在内存中以备使用，这样它就只是一个mem副本呢？那当然很快

啊，现在我们之间有了一个叫做互联网的慢东西，它阻碍了用户体验，限制了我们可以使用的内容，我们如何提前预计算页面，将它们全部存档，并在用户本地机器上运行？那太快了

但这将浪费cpu周期，很多，还有页面加载时间和浏览器内容呈现等，我们将跳过中间人，只需