说真的，我应该编写糟糕的 PHP 代码吗？ [关闭]答案

【问题标题】：Seriously, should I write bad PHP code? [closed]说真的，我应该编写糟糕的 PHP 代码吗？ [关闭]
【发布时间】：2008-10-09 14:50:10
【问题描述】：

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

这是真的吗，即使 PHP 页面已被编译和缓存？我应该尽可能避免使用方法来提高效率吗？我喜欢编写组织良好、人类可读的代码，其中包含重复代码块的方法。如果需要编写没有方法的平面代码，是否有任何程序可以“内联”方法体？这样我就可以编写漂亮的代码，然后在部署之前将其丑化。

顺便说一句，我一直在查看的代码来自 Joomla 1.5 核心和几个 WordPress 插件，所以我认为他们是知道自己在做什么的人。

注意：我很高兴每个人都跳到这个问题上来讨论一般情况下的优化，但实际上我们是在讨论解释语言中的优化。至少可以暗示我们正在谈论 PHP 的事实。

【问题讨论】：

PHP 与否，如果没有某种衡量标准，就不可能说出你应该做什么或不应该做什么。
实际上，您在帖子末尾做了一个错误的假设。一些最流行的 PHP 项目的代码不那么出色。想到了 OSCommerce、Wordpress 和 Drupal。流行！=精心设计。
任何已经存在 4 或 5 年的 PHP 应用程序都是用一种与今天的 PHP 完全不同的语言编写的。 OO 只是一个承诺的暗示。
还要考虑心理影响：与编写可能执行得更快的丑陋代码相比，编写可能执行速度较慢的漂亮代码会感觉更好。让人类对自己所做的事情感觉良好很重要。
我会将 Drupal 从不太出色的代码中排除。 OO 不是一切：drupal.org/node/547518 .

标签： php optimization code-generation translation

【解决方案1】：

您需要多少“效率”？你还量过吗？过早的优化是万恶之源，没有衡量的优化总是过早的。

还要记住rules of Optimization Club。

优化俱乐部的第一条规则是，你不要优化。
优化俱乐部的第二条规则是，没有衡量就不要优化。
如果您的应用运行速度快于底层传输协议，则优化结束。
一次一个因素。
没有市场机器人，没有市场机器人时间表。
只要需要，测试就会继续进行。
如果这是您在优化俱乐部的第一晚，您必须编写一个测试用例。

【讨论】：

太棒了。已收藏。
安迪，这本身可能是一个问题，但是您如何衡量您的应用程序运行速度比传输协议快？它仍然需要通过运输来打磨，对吧？
规则的前提是，如果你是 I/O 绑定的，那么担心函数开销是没有意义的。如果你用一秒钟来计算一个数据桶，然后用 10 秒钟将它通过网络传输到磁盘，不管怎样，那么看看这 10 秒钟，而不是那一秒钟。
SomeAnalogy extends FightClub 是禁止的。
生活可能充满失望。

【解决方案2】：

我认为 Joomla 和 Wordpress 并不是优秀 PHP 代码最好的例子，这没有冒犯。我对从事这项工作的人没有任何个人意见，他们使人们拥有网站/博客的方式很棒，而且我知道很多人将所有空闲时间都花在了这两个项目中，但是代码质量相当差（无意冒犯）。

如果您不相信我，请查看过去一年的安全公告；还假设您正在寻找两者中的任何一个的性能，他们的代码在那里也不擅长。所以这绝不是好的代码，但 Wordpress 和 Joomla 都在前端表现出色 - 非常易于使用，人们获得了一个网站并且可以做 stuff。

这就是它们如此成功的原因，人们不是根据代码质量来选择它们，而是根据它们使它们能够做什么。

要回答您的性能问题，是的，确实所有好东西（函数、类等）都会减慢您的应用程序的速度。所以我想如果你的应用程序/脚本都在一个文件中，那就这样吧。请随意编写糟糕的 PHP 代码。

一旦扩展并开始复制代码，就应该考虑编写可维护代码所带来的权衡（在速度方面）。 :-)

恕我直言，这种权衡相当小，原因有两点：

CPU 很便宜。
开发者并不便宜。

当您需要在六个月后重新开始编写代码时，想想如果那些纳秒的运行时间节省了运行它，那么当您需要修复一个令人讨厌的错误时（三到四次，因为重复的代码）仍然加起来。

你可以做各种各样的事情来让 PHP 运行得更快。一般人推荐一个缓存，比如APC。 APC真的很棒。它在后台为您运行各种优化，例如缓存 PHP 文件的字节码，并为您提供用户空间中的函数来保存数据。

因此，例如，如果您每次运行该脚本时都解析一个配置文件，那么磁盘 i/o 就非常关键。使用简单的apc_store() 和apc_fetch()，您可以将解析后的配置文件存储在基于文件或基于内存 (RAM) 的缓存中，然后从那里检索它，直到缓存过期或被删除。

当然，APC 不是唯一的缓存。

【讨论】：

这个问题的答案和更多我想要的一切！感谢分享。
我想知道是不是只有我认为 Wordpress 代码真的很差。

【解决方案3】：

您应该会看到对此问题的回复：Should a developer aim for readability or performance first?

总结共识：除非您知道（通过测试/分析）需要在某些特定领域解决您的性能问题，否则可读性更为重要。

【讨论】：

【解决方案4】：

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

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

【讨论】：

Facebook 使用 PHP，因此显然性能关键的网站可以在 PHP 上运行。不要传播 FUD。
这不是 FUD - 如果需要对代码进行超级优化，解释型语言不是可行的方法。
在 PHP 中 could 解决的可能应用程序会有这样的性能要求，以至于在 PHP 中太慢？这绝对是 FUD。
@Guido：也许您应该考虑改写第二句话或完全删除它。我 100% 同意你的看法——编写可理解、可测试和可维护的代码远比担心性能要重要得多——但是直接攻击 PHP 已经将你引向了一个令人反感的标志，它把我带到了这里。可能是这样的......“在那些性能确实很关键的少数情况下，像 PHP 这样的脚本语言不是你的最佳选择。毕竟，PHP 中的许多基础库函数都是用 C 编写的。”
完成。我不是故意冒犯的。

【解决方案5】：

就个人而言，虽然函数调用可能会产生开销，但如果这意味着我编写了一次代码（参数化），然后在 85 个地方使用它，我就WAY更进一步，因为我可以在一个地方修复它。

脚本语言往往会让人认为“足够好”和“有效”是编码时要考虑的唯一标准。

【讨论】：

【解决方案6】：

特别是对于像 PHP 这样的快速解释器，我认为缺乏可读性/可维护性并不值得您可能（或可能不会！）从中获得效率。

还有一个关于 WordPress 的说明：我已经浏览了很多 WordPress 代码。请不要假设那些人对好的代码一无所知。

【讨论】：

WordPress 的质量如此真实。
你有 PHP 代码的好例子吗？说一个开源应用？

【解决方案7】：

要回答您的第一个问题，是的，这是正确的，对于编译的操作码也是如此。是的，您可以通过避免函数调用来使您的代码更快，除非您的代码因代码重复而变得过大的极端情况。

你应该做你喜欢做的事“我喜欢用方法编写组织良好、人类可读的代码，只要代码块会被重复。”

如果您要犯下删除所有函数调用的可怕暴行，至少使用分析器并且只对重要的 10% 代码执行此操作。

【讨论】：

【解决方案8】：

微观优化如何导致宏观放缓的一个例子：

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

JMP 很昂贵，如果您可以通过展开来消除循环并消除所有条件块，那么您将消除仅仅在 CPU 缓存中寻找所浪费的所有时间。

运行时的变量扩充也很慢，就像从数据库中提取数据一样，因此您也应该将所有数据内联到您的代码中。

实际上，加载解释器仅用于执行代码并将内存复制到用户是非常浪费的，为什么我们不预先计算所有可能的页面并将每个页面存储在内存中准备好这样它只是一个内存拷贝？那肯定很快！

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

但这会浪费大量的 cpu 周期，还有页面加载时间和浏览器内容渲染等，我们将跳过中间人，直接通过印刷媒体将页面交付给他们！天才！。

/me 眼睁睁地看着你的公司倒闭，而你却花了 10 年时间（手工）预先计算和打印没人愿意看到的页面。

这对你来说可能听起来很傻，但对我们其他人来说，你的提议就是那么荒谬。

优化是好的，但在合理的地方划清界限，这样您就不必担心未来的代码工作人员会在您睡梦中跟踪您，因为您拥有如此糟糕的无法维护的代码库。

注意：是的，我使用的是 gentoo。你怎么猜的？

【讨论】：

我刚刚发现这个冗长复杂的答案实际上很酷。确实如此：优化与可读性是一个可以任意选择的分界点。

【解决方案9】：

当然，您不应该编写糟糕的 PHP 代码。但是一旦你写了不好的东西，你可能总是以性能为借口:-)

【讨论】：

不错！有选择是件好事。

【解决方案10】：

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

另见：

Wikipedia -> Optimization -> When to optimize

c2.com Wiki -> Premature Optimization

【讨论】：

【解决方案11】：

PHP 的主要优势在于它可以快速轻松地获得工作应用程序。这种优势来自于编写松散（坏）代码并使其仍然以某种预期方式运行的机会。

如果您需要节省几个 CPU 周期，那么您不应该使用 PHP。当 PHP Web 应用程序性能不佳时，更有可能是由于查询效率低下，而不是代码执行速度。

【讨论】：

【解决方案12】：

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

说真的，如果您正在为运行速度编码，那么您根本不应该使用 PHP。

【讨论】：

【解决方案13】：

如果您使用 MVC 架构模式开发 Web 应用程序，您可以从缓存和序列化中受益匪浅。您可以缓存视图或部分视图，还可以序列化模型。

根据经验，模型通常会解析并生成大部分显示的数据。如果您知道某个模型不会频繁生成新数据，例如解析 RSS 提要的模型，您可以将所有已解析的数据填充到某个地方，并每隔一段时间刷新一次。

【讨论】：

【解决方案14】：

如果您查看 wordpress php 代码，它会在其 html 之间混合 php 标签，这在我的脑海中导致了意大利面条。

然而，Phpbb3 在这方面要好得多。例如，它在 php 部分和样式部分之间有严格的划分，样式部分是带有 {template} 标签的 xhtml 格式文件，由模板引擎解析。哪个更干净。

【讨论】：

【解决方案15】：

编写几个 10 分钟的示例并在您的分析器中运行它们。

这会告诉你哪个更快到毫秒。

如果您没有分析器，请将它们发布在这里，我将在我的 PHPEd 分析器中运行它们。

我怀疑大部分时间差异（如果有的话）来自必须打开存储类的文件，但这也必须进行测试。

然后问问自己，您是否在意几毫秒而不是维护意大利面条式代码 - 您的用户会注意到吗？

编辑

分析器不会模拟高流量，但它会告诉您哪种方法对单个用户更快，以及代码的哪些部分使用了多少时间。特别是如果您对重复执行的操作进行概要分析 - 比如说每个循环 1000 次。

我们可以假设（尽管并非总是如此）很多人使用的速度更快的代码会比很多人使用的速度慢的代码更快。

【讨论】：

PHP 的性能在并发负载下不会降低太多（除非你做一些愚蠢的事情，比如产生 4000 个解释器）。最会降低数据库性能的是数据库性能（尤其是如果你做了一些愚蠢的事情，比如使用 MyISAM）。

【解决方案16】：

那些会教你代码微优化的人通常是相同的，每页有 50 个 SQL 查询，总共需要 2 秒，因为他们从未听说过 profiling。但是他们的代码被优化了！！！（而且慢得要命）

事实：添加另一个网络服务器并不困难。复制数据库是。如果优化网络服务器代码会增加数据库的负载，则可能会造成净损失。

注意：包括 SQL 在内的简单页面（如论坛主题）的 2-3 毫秒对于 PHP 网站来说是一个很好的目标。我的旧网站曾经这样做过。

【讨论】：

确实如此。你推荐什么来分析 PHP？
除了在页面底部打印在 PHP 代码中花费的总时间供管理员查看外，我通常不会分析 PHP。这通常是所有需要的分析。如果您使用代码缓存并且代码相当好，PHP 就足够快了。我所做的配置文件是 SQL 查询：因为我使用了一个简单的包装器，它自动转义参数，它记录所有查询和查询时间，并在每个页面的底部打印一个查询 + 时间列表（当然只有当用户是管理员时)。