速度比较 - 解释语言中的程序与OO

时间:2008-08-06 03:34:02

标签: performance oop maintainability procedural interpreted-language

在解释性编程语言中,例如PHP和JavaScript,采用面向对象方法而不是程序方法会产生什么影响?

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

结论:当用解释语言中的OO与Procedural进行比赛时,真正的性能有多大(如果有的话)?

7 个答案:

答案 0 :(得分:17)

也许我疯了但是在使用解释性语言这样的情况下担心速度就像试图弄清楚用什么颜色来画棚子。让我们甚至不认为这种优化完全是成熟的。

当你说'可维护性'时,你的头上钉了一针。我会选择最有效率和最易维护的方法。如果您以后需要速度,则不会在解释语言中切换过程与面向对象的编码范例。

答案 1 :(得分:10)

不幸的是,我也完成了我的测试。我做了测试速度,它大致相同,但是在测试内存使用情况下获取PHP中的memory_get_usage()时,我在OOP端看到了一个非常大的数字。

对于程序,

116,576字节用于OOP到18,856字节。我知道“硬件便宜”,但加油!使用量增加1,000%?对不起,这不是最佳选择。有这么多用户同时访问您的网站,我确信您的RAM只会燃烧或耗尽。我错了吗?

答案 2 :(得分:4)

底线:不,因为解释的开销超过了方法调度的开销。

答案 3 :(得分:2)

根据我的经验,使用OOP代码比使用OOP代码更容易使负载较重的站点陷入困境并且变得无响应。原因很容易理解。

OOP需要更多的内存分配(MALLOC),并且在内存中运行的操作比程序代码要多得多。它需要更多的CPU时间来执行其任务。它基本上是“开销”,包含在程序代码中,增加了执行它的CPU负担,特别是在执行数据库操作时。

许多程序员喜欢OOP的便利性,在简单的界面后面创建了一些黑盒子。但是,我已经很好地恢复了在重度用户负载下永远响应的网站。剥离OOP并用简单的程序函数替换它会产生巨大的差异。

如果您不希望您的网站非常繁忙,请务必使用OOP。如果要构建高流量系统,则需要从处理中删除每个CPU周期,并从输出中删除每个字节。

答案 4 :(得分:1)

您的表现将以实施为特征,而不是语言。您可以使用最慢的语言,只要您按比例设计它就可以扩展为世界上最大的网站。

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

别。

:)

答案 5 :(得分:1)

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

答案 6 :(得分:0)

我实际上在我维护的网站上在python中做了一个这样的小测试,发现它们的速度几乎相同,程序方法赢得了万分之一秒,但是OO代码如此清洁,我没有比一次迭代更长时间地继续锻炼。

所以,真的,无论如何(根据我的经验)。