我最近在做一些 PHP 工作，在我见过的所有代码中，人们倾向于使用很少的方法。（他们也倾向于使用很少的变量，但这是另一个问题。）我想知道为什么会这样，我发现了这个注释“带有一个参数和一个空函数体的函数调用与执行 7-8 $ 所花费的时间大致相同localvar++ 操作。类似的方法调用当然是大约 15 个 $localvar++ 操作” here。
这是真的吗，即使 PHP 页面已被编译和缓存？我应该尽可能避免使用方法来提高效率吗？我喜欢编写组织良好、人类可读的代码，其中包含重复代码块的方法。如果需要编写没有方法的平面代码，是否有任何程序可以“内联”方法体？这样我就可以编写漂亮的代码，然后在部署之前将其丑化。
顺便说一句，我一直在查看的代码来自 Joomla 1.5 核心和几个 WordPress 插件，所以我假设他们是知道自己在做什么的人。
注意：我很高兴每个人都跳到这个问题上来谈论一般的优化，但实际上我们谈论的是解释语言中的优化。至少我们正在谈论 PHP 的事实的一些暗示会很好。
你需要多少“效率”？你还量过吗？过早的优化是万恶之源，没有度量的优化总是过早的。
还要记住优化俱乐部的规则。
我认为 Joomla 和 Wordpress 并不是优秀PHP 代码的最好例子，这没有冒犯。我对从事这项工作的人没有任何个人意见，他们使人们拥有网站/博客的方式很棒，而且我知道很多人将所有空闲时间都花在了这两个项目中，但是代码质量相当差（没有冒犯的意思）。
如果您不相信我，请查看过去一年的安全公告；还假设您正在寻找两者中的任何一个的性能，他们的代码在那里也不擅长。所以这绝不是好的代码，但 Wordpress 和 Joomla 在前端都表现出色 - 非常易于使用，人们可以获得一个网站并且可以做一些事情。
这就是它们如此成功的原因，人们不是根据代码质量来选择它们，而是根据它们使它们能够做什么。
要回答您的性能问题，是的，确实所有好东西（函数、类等）都会减慢您的应用程序的速度。所以我想如果你的应用程序/脚本都在一个文件中，那就这样吧。随意编写糟糕的 PHP 代码。
一旦扩展并开始复制代码，就应该考虑编写可维护代码带来的权衡（速度）。:-)
恕我直言，由于两件事，这种权衡相当小：
当您需要在六个月后返回您的代码时，想想如果那些纳秒节省了运行它，当您需要修复一个讨厌的错误时（三到四次，因为重复的代码）仍然加起来。
你可以做各种各样的事情来让 PHP 运行得更快。通常人们推荐一个缓存，例如APC。APC真的很棒。它在后台为您运行各种优化，例如缓存 PHP 文件的字节码，还为您提供用户空间中的函数来保存数据。
因此，例如，如果您每次运行该脚本磁盘 i/o 时都解析一个配置文件，这真的很关键。使用简单的apc_store()和apc_fetch()您可以将解析的配置文件存储在基于文件或基于内存 (RAM) 的缓存中，并从那里检索它，直到缓存过期或被删除。
当然，APC 不是唯一的缓存。
您应该看到对这个问题的回答：开发人员应该首先考虑可读性还是性能？
总结共识：除非您知道（通过测试/分析）您的性能需要在某些特定领域解决的事实，否则可读性更为重要。
在 99% 的情况下，您应该更好地担心代码的可理解性。编写易于测试、理解和维护的代码。
在性能确实很关键的少数情况下，像 PHP 这样的脚本语言不是您的最佳选择。毕竟，PHP 中的许多基础库函数都是用 C 编写的，这是有原因的。
就个人而言，虽然函数调用可能会有开销，但如果这意味着我编写了一次代码（参数化），然后在 85 个地方使用它，那么我会走得更远，因为我可以在一个地方修复它。
脚本语言倾向于给人们这样的想法，即“足够好”和“有效”是编码时要考虑的唯一标准。
特别是对于像 PHP 这样的快速解释器，我不认为缺乏可读性/可维护性是值得你可能（或可能不会！）从中获得的效率。
还有一个关于 WordPress 的说明：我已经浏览了很多 WordPress 代码。请不要假设那些人对好的代码一无所知。
要回答您的第一个问题，是的，这是真的，编译的操作码也是如此。是的，您可以通过避免函数调用来使您的代码更快，除非您的代码因代码重复而变得过大的极端情况。
你应该做你喜欢做的事“我喜欢用方法编写组织良好、人类可读的代码，只要代码块会重复出现。”
如果您要犯下删除所有函数调用的可怕暴行，至少使用分析器并且只对重要的 10% 代码执行此操作。
微观优化如何导致宏观放缓的一个例子：
如果您正在认真考虑手动内联函数，请考虑手动展开循环。
JMP 很昂贵，如果您可以通过展开来消除循环并消除所有条件块，那么您将消除仅仅在 CPU 缓存周围寻找所浪费的所有时间。
运行时的变量扩充也很慢，就像从数据库中提取数据一样，因此您也应该将所有数据内联到您的代码中。
实际上，加载一个解释器来仅仅执行代码并将内存复制给用户是非常浪费的，为什么我们不预先计算所有可能的页面并将每个页面存储在内存中准备好它只是一个内存副本? 那肯定很快！
啊，现在我们之间有了一个叫做互联网的慢东西，它阻碍了用户体验并限制了我们可以使用的内容量，我们如何提前预先计算页面，并将它们全部存档并在用户本地机器？那会非常快！
但这会浪费大量的 cpu 周期，还有页面加载时间和浏览器内容渲染等，我们将跳过中间人，只在印刷媒体上将页面交付给他们！天才！。
/me 眼睁睁地看着你的公司倒闭，而你却花了 10 年时间（手工）预先计算和打印没人愿意看到的页面。
这对你来说可能听起来很傻，但对我们其他人来说，你的提议就是那么荒谬。
优化是好的，但是在合理的地方划清界限，这样你就不必担心未来的代码工作人员会在你睡梦中跟踪你，因为有一个无法维护的糟糕代码库。
注意：是的，我使用 gentoo。你怎么猜的？
当然，您不应该编写糟糕的 PHP 代码。但是一旦你写了不好的东西，你可能总是以性能为借口:-)
这是过早的优化。虽然函数调用的成本高于增加局部整数变量的说法是正确的（几乎所有的成本都更高），但与数据库查询相比，函数调用的成本仍然非常低。
也可以看看：
PHP 的主要优势在于它可以快速轻松地获得一个工作应用程序。这种优势来自于编写松散（糟糕）代码并使其仍然以某种预期方式运行的机会。
如果您需要节省一些 CPU 周期，那么您不应该使用 PHP。当 PHP Web 应用程序性能不佳时，更有可能是由于查询效率低下，而不是代码执行速度。
如果您担心效率的每一点，那么您到底为什么要使用脚本语言？您应该使用一种更快的语言进行编程（在此处插入您最喜欢的编译语言），这可能会导致代码的可读性越来越多，但它会运行得非常快，并且您仍然可以瞄准最佳编码实践。
说真的，如果您正在为运行速度编码，那么您根本不应该使用 PHP。
如果您使用 MVC 架构模式开发 Web 应用程序，您可以从缓存和序列化中受益匪浅。您可以缓存视图或其中的一部分，并且可以序列化模型。
根据经验，模型通常会解析并生成大部分正在显示的数据。如果您知道某个模型不会频繁生成新数据，例如解析 RSS 提要的模型，您可以将所有解析的数据填充到某个地方，并每隔一段时间刷新一次。
如果您查看 wordpress php 代码，它会在其 html 之间混合 php 标签，这导致我想到意大利面条。
然而，Phpbb3 在这方面要好得多。例如，它在 php 部分和样式部分之间有严格的划分，样式部分是带有 {template} 标签的 xhtml 格式文件，由模板引擎解析。哪个更干净。
编写几个 10 分钟的示例并在您的分析器中运行它们。
这会告诉你哪个更快到毫秒。
如果您没有分析器，请在此处发布它们，我将在我的 PHPEd 分析器中运行它们。
我怀疑大部分时间差异（如果有的话）来自必须打开存储类的文件，但这也必须进行测试。
然后问问自己，你是否在乎几毫秒而不是维护意大利面条式代码——你的用户会注意到吗？
编辑
分析器不会模拟高流量，但它会告诉您哪种方法对单个用户更快，以及代码的哪些部分使用了多少时间。特别是如果您对重复执行的操作进行概要分析 - 例如在循环中每次执行 1000 次。
我们可以假设（尽管并非总是如此）很多人使用的更快的代码会比很多人使用的慢速代码更快。
给你讲代码微优化的人，一般都是每页有 50 个 SQL 查询，总共需要 2 秒，因为他们从来没有听说过 profiling。但是他们的代码被优化了！！！（而且慢得要命）
事实：添加另一个网络服务器并不困难。复制数据库是。如果优化网络服务器代码增加了数据库的负载，那么它可能会造成净损失。
注意：包括 SQL 在内的简单页面（如论坛主题）的 2-3 毫秒对于 PHP 网站来说是一个很好的目标。我的旧网站曾经这样做过。