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

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 代码是如此显着更清洁 我没有继续这个练习超过一次迭代。

所以说真的，这并不重要（无论如何，根据我的经验）。