速度比较 - 解释型语言中的过程与面向对象

Question

在解释性编程语言（例如 PHP 和 JavaScript）中，使用面向对象方法而不是过程方法会产生什么影响？

具体来说，我正在寻找的是在创建 Web 应用程序并在面向过程和面向对象方法之间进行选择时要考虑的事项清单，不仅要优化速度，还要优化可维护性。 如果您知道任何进一步探讨此问题的文章，引用的研究和测试用例也会有所帮助。

底线：在解释性语言中使用面向对象与程序化时，性能受到的影响到底有多大（如果有的话）？

Answer 1

也许我疯了，但在这种情况下使用解释性语言担心速度就像试图弄清楚要给棚子涂上什么颜色。 我们甚至不要认为这种优化完全是过早的。

当您说“可维护性”时，您一针见血。 我会选择最高效和最易于维护的方法。 如果您以后需要速度，它不会来自在解释语言中的过程与面向对象编码范式之间的切换。

Answer 2

不幸的是，我也做了我的测试。 我确实测试了速度，并且大致相同，但是在测试内存使用情况时，在 PHP 中获取 memory_get_usage() 时，我在 OOP 方面看到了压倒性更大的数字。

OOP 为 116,576 字节，过程为 18,856 字节。 我知道“硬件很便宜”，但是来吧！ 使用量增加 1,000%？ 抱歉，这不是最佳选择。 有这么多用户同时访问您的网站，我敢肯定您的 RAM 会烧毁或耗尽。 我错了吗？

Answer 3

底线：不，因为解释的开销压倒了方法调度的开销。

Answer 4

根据我的经验，与程序相比，使用 OOP 代码的网站在高负载下会更容易陷入困境并变得无响应。 原因很容易理解。

与过程代码相比，OOP 需要更多的内存分配 (MALLOC) 和在内存中运行的更多操作。 它需要更多的 CPU 时间来执行其任务。 它本质上是“开销”，围绕着过程代码，增加了执行它的 CPU 负担，尤其是在执行数据库操作时。

许多程序员喜欢 OOP 的便利，创建隐藏在简单接口后面的小黑盒子。 但是，我已经获得了丰厚的回报，以恢复在繁重的用户负载下需要永远响应的网站。 剥离 OOP 并用简单的过程函数替换它会产生巨大的差异。

如果您不希望您的站点非常繁忙，请务必使用 OOP。 如果您正在构建一个高流量系统，您将希望从处理中剥离每个 CPU 周期，并从输出中剥离每个字节。

Answer 5

你的表现将取决于实现，而不是语言。 你可以使用最慢的语言，它可以扩展成为世界上最大的网站，只要你设计它可以扩展。

请记住优化的第一条规则。

别。

:)

Answer 6

如果您使用的是解释型语言，则差异无关紧要。 如果性能是一个问题，您不应该使用解释性语言。 两者的表现大致相同。

Answer 7

我实际上在我维护的网站上用 python 做了一个这样的小测试，发现它们的速度几乎相同，程序方法以大约一万分之一秒的优势获胜，但是 OO 代码是如此显着我没有继续练习超过一次迭代。

所以真的，没关系（无论如何，以我的经验）。